FOUNDRY News

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/

Hello everyone!

A few blog posts ago we promised to show a new modular building on the next FOUNDRY Friday and instead covered a different topic in the following post. Since we received a few “reminders” I wanted to address this grave injustice and hereby finally show the work in progress art of the new power plant!


What you can see is a power plant that is made out of several different modular buildings. I once mentioned that one of the main motivations for modular buildings was that in reality it’s more likely to have a single large machine than hundreds of small ones working in parallel. A power plant made of multiple such buildings is the next logical step. We’re trying to make those objects - especially once combined - feel like real buildings. In fact, some of them are so massive you can enter them.


Its functionality is inspired by real life nuclear power plants, although a bit simplified. We haven’t yet decided if we’ll theme it as a nuclear plant or if we’re going to come up with a more sci-fi-ish design.


Your task is to build those buildings and properly connect each of them. As we are still working on this I won’t go further into detail but instead share screenshots.


Please note that things are subject to change as everything is work in progress.

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/