FOUNDRY News

Hello everyone!

Today we are going to take a look at some of the new commerce features we have been working on over the past months and how the early game is changing.

As a reminder, we are making those changes to give the factory (and the game overall) a more motivating and less linear goal to work towards. These new features complement the existing research progression and give that game a more unique feeling.

In case you want a more detailed recap about why we’re making those adjustments to the game, check some of our other dev blogs here and here.

[h3]Adjusted Setting[/h3]
We have modified the onboarding loop and the overall setting, you’re no longer the clueless robot trying to figure out what went wrong with the initiative to build a large factory on the planet. Instead you have just acquired a derelict space station and colonization rights on the resource rich moon the station orbits. Your intent is to set up an intergalactic robot manufacturing company. You’re still assisted by Carl and C3-BB who will help you get started. Your immediate goal is to build up the most critically required machinery to start making simple robots, repair the most broken parts of the station and begin selling your first product. Oh and did I mention that you’re in debt?

What mattered most to us is that the new theme is a key part of the game from the very beginning. It won't take you countless hours to finally make and sell a robot, instead you will accomplish this by the end of the tutorial - which is slightly longer than before, but not by a lot. We always planned to focus on commerce to give the player a good reason to build the factory, but our previous game loop brought those key mechanics way too late.



[h3]Onboarding and Tutorial Tasks[/h3]
The onboarding tasks are similar until you build the beacon to call down C3-BB at which point new mechanics are introduced. You’re immediately tasked with making contact with the station and analyzing its status. We’ve reworked the space station management UI.

UI screenshots are work in progress

This is the main hub for all things related to the space station and it comes with new features and greater depth. Initially, you’ll only be able to open this management console from a building, but as you progress, a remote view will be unlocked.



The following tasks will be a mixture of introducing space station features, such as building and upgrading parts, and continuing to build up your factory so that you’re set to make your first very simple robot.

Since robots are sold through your station, the final missing link is to get your products up there. For this, we have introduced a new building which we call the Shipping Pad; it is more flexible and replaces the old way of moving things to the station. Once placed you need to select the shipping direction (planet to station or vice-versa) and which item should be moved. The shipping pad doesn’t come with any transport vessel, so we need to head back to the station and make our first purchase: A small cargo space ship. Once assigned to the shipping task your items are automatically being moved between the planet and the station.

In this blog, I won’t go into too much detail, but space ships will have a bunch of tasks and you’ll be managing quite a few of them. That being said I want to emphasize that almost all your gameplay time is still spent on building a factory, we are not transforming the key gameplay in any way.

Okay, almost there. The final step is to extend the station with a sales terminal where casual customers will buy what’s in store. Given how much you’re producing, you can play around with applying discounts or premiums to maximize your income, but that is up to you.

UI screenshots are work in progress

Ultimately there will be way more profitable (and complex!) ways throughout the galaxy to sell your products, but that is for the next commerce preview blog.

See you next time,
-mrmcd



Follow us on socials:

• Discord
• Twitter
• Reddit
• Facebook
• Paradox Forum

Stay tuned for more news!

https://store.steampowered.com/app/983870/FOUNDRY/

Hello everyone!

Today I want to share a new and exciting feature with you: A selection screen for different starting planets. When you start a new game you’ll be able to select one of multiple planets, which feature different resource and biome modifications.



This has been a feature that we somewhat coincidentally stumbled into while we’re working on the commerce update. As you know immersion has always been something we care about deeply and for the new commerce theme (more information in future dev blogs) it is a great fit to let you select the planet you want to start your factory on.

At the current state of development we’re very focused on the core features and changes necessary to get the new update done as soon as possible, therefore I initially assumed different starting planets aren’t going to happen. But as we contemplated the topic a bit we realized that we already have systems to make this work: Our world generation system supports customizable resource settings (density & richness for all ores and liquids) and we have a system we call “biome grid”, which allows us to tell the world generator how biomes are distributed around the world. All we had to do was add support for different presets that can be tied to different starting planets.


We decided to allow the players to further customize the resource distribution settings as they were able before, selecting a planet just applies certain default settings, but you’ll be free to further adjust as you see fit.

The biome grids however are static per planet and cannot be changed. The way we are going to utilize the biome grid system is that it’ll allow us to over- or underrepresent certain biomes to give the planet a different vibe. For example to make it into a (mostly) desert or ice planet. So let us take a look at a biome grid:


What you can see here is a grid with different colors per box. One axis represents the temperature and the other axis represents the precipitation (both from high to low), the two metrics used (derived from noise based procedural generation) for the world generator to decide which biome to place. Each grid box represents the biome the world generator will use for the according combination of values. For example when it’s hot and humid we assign the tropical rainforest, while if it’s hot and dry it’s a desert. Having different presets per planet allows us to easily generate a very different planet.

Of course it would be even better to have more differences like different configurations on mountain and river settings, but those are things we view as stretch goals that can be looked at at later times during our Early Access period. For now this is a great feature to increase replayability and player choice for a comparatively low amount of work on our side.

I’m going to conclude today’s blog with two different videos of a desert and an ice planet.

[previewyoutube][/previewyoutube]
Thanks for reading and see you next time,
-mrmcd



Follow us on socials:

• Discord
• Twitter
• Reddit
• Facebook
• Paradox Forum

Stay tuned for more news!

https://store.steampowered.com/app/983870/FOUNDRY/

Hello again!
My name is Jason, the art director of Foundry. In this week’s ‘Foundry Fridays’ dev diary, I’m showing progress on a new biome.

This choice to go with a cold climate biome was only natural 🙂 We wanted an environment that was an opposing counterpart to the rocky desert biome. There is still some work to be done on tuning density and variety of vegetation for biomass resources, but we’re happy with how it’s turning out so far and makes a great addition to the other current biomes already in the game.


I love how the water all of a sudden looks very cold when next to snow covered terrain.


[h3]Breaking It Down[/h3]
Here are some of the rocks and vegetation used to generate the biome. Trees look thick and tough to withstand the cold temperatures. Rock pillars' shapes are sharp and sheer to contrast against the rocky desert counterparts. Winter flowers add accents of colour to the frosty white surroundings.


Stay tuned to see more of this little guy hobbling around the snowy landscapes 🙂


So there you have it. Short and sweet. Until next time!
Jason



Follow us on socials:

• Discord
• Twitter
• Reddit
• Facebook
• Paradox Forum

Stay tuned for more news!

https://store.steampowered.com/app/983870/FOUNDRY/

Greetings Founders!

From all of us at Foundry, we wish you all a happy new year. As some of you may know, we’ve been hard at work at expanding the gameplay side of Foundry. For example, with the recently announced trains we want to allow the player to make factories that span the entire map. But as the factory expands, we have to make sure that it runs properly for our players, even on portable devices like the Steam Deck.

While going through some save files from users that had reported performance issues, we came across a particular condition that would make the game’s performance come to a crawl. By profiling it, we discovered that the game would sometimes spend up to a third of the time that it took to render a frame just on the screen panels of machines. Here’s a screenshot of the mere 27 FPS within a base that definitely needs some performance improvements.

The benchmark place, where performance goes to die…

For the screen panels we already had some optimizations in place to not update the text or contents of the screen panel every frame, but rather periodically. This load balancing trick is used in many systems throughout Foundry, and it prevents the game from suddenly having large stutters when you move around your camera or a power outage hits your base.

However, even though we update the contents of the screens only every few frames, Unity will still have to render each of the 36 screens in the above screenshot one-by-one, each consisting of multiple steps. This is unlike the 3D geometry of the buildings, which are rendered using GPU instancing which makes it cheap to render either 10 or 100 buildings on the screen.

To address this, we thought that it’d made sense to only re-render the screen panels when the screen contents get rendered. Since our screen panels already uses Unity’s UI system and it would take a long time to make a comparable UI system, we opted for trying to get Unity’s UI to rerender periodically. However, to do this we need to take full control over Unity’s UI rendering and replicate how Unity renders the UI of the screens ourselves.

After having done exactly that, the game is now able to render all the screen panels of all the buildings in the world to this single texture. By only updating a single screen per-frame, we avoid the large cost of having to re-render hundreds of individual widgets of the screen panels. And to avoid losing responsiveness when a user wants to read or interact with the screen, the game will only use this optimization at far away distances at various smaller resolutions.

An example of how the various screen panels are all tightly packed into this texture

The last step is to replace the regular screen panel rendering with the versions that are drawn inside this texture atlas cache, as we internally refer to it. Using the same GPU instancing that we use for the assemblers and many of the other buildings, we can draw both old and newly rendered texture just by a single render instruction for the GPU.

The same place, but now optimized!

And the end result is… pretty decent. In this benchmark factory we went from 27 FPS to 32 FPS, which is a 16% improvement that might affect quite a few of our player’s factories out there. This optimization made the screen rendering itself 33% faster in this specific location, but we also no longer risk the issue of having too many screen panels being rendered at the same time since the custom rendering system will only update up to a certain amount of screens anyway. We also have a lot of room for performance improvements regarding the screens now that they’re manually rendered.

I hope this somewhat technical breakdown was understandable enough! For future reports, we’ll try to get back to a more relaxed angle, but I think this was a great example to explain some of the behind-the-screen tricks we use to improve the performance in our game.
- Milan



Follow us on socials:

• Discord
• Twitter
• Reddit
• Facebook
• Paradox Forum

Stay tuned for more news!

https://store.steampowered.com/app/983870/FOUNDRY/

Merry Christmas from the FOUNDRY-Team!

[previewyoutube][/previewyoutube]


Follow us on socials:

• Discord
• Twitter
• Reddit
• Facebook
• Paradox Forum

Stay tuned for more news!

https://store.steampowered.com/app/983870/FOUNDRY/