FOUNDRY News

Hello everyone!

It’s Friday again and here is our Foundry Friday Blog! Today I bring information about our Assembly Lines and the robots they assemble. A feature we have announced a while ago but have been pretty quiet ever since. This time we don’t need a long paragraph of text to get started, let’s jump right into it with a video:

[previewyoutube][/previewyoutube]
Please note that everything shown in this post is still work in progress and not yet representative of the final version.

[h3]Motivation[/h3]
Now that you’ve seen what it’s all about, let’s look at what motivated me to add this feature: To me it always felt like missed potential that you produce so many different items while playing a factory game, yet you rarely see how any of the items are actually made. Machines take certain items as input and after a few seconds something else comes out on the other side. And while there are options to add a little more immersion with machines similar to 3D-printers (where the output item is faded in) I always wanted to go further.


[h3]Scope[/h3]
The reason why it’s uncommon to visualize the process of items being made is simple: It’s very difficult and takes a lot of effort. It requires animations, models, engineering work, and lots of polishing to bring it all together. On top of that it also comes with a performance cost so it needs optimization work. Therefore we settled for a middle ground where we are going to visualize the assembly of our final products, the things you work towards and have the most impressive looks.

For now that means that most of FOUNDRY’s gameplay stays the same while you will be building those assembly lines for our end products. Depending on reception of this feature we might go further and visualize more product manufacturing in future updates. Especially in the metallurgy part of the game I see a lot of additional potential.


[h3]Robots[/h3]
You’ve seen the videos and gifs, we’re making robots! We’ve been quiet about the end products in FOUNDRY but now we can finally share the secret: You’re going to produce robots, lots of robots. Different models too. However, “why” is a question that we are going to leave unanswered for now. Feel free to speculate in our Discord, we enjoy reading all the guesses, maybe someone gets it right?

Robots work really well when you want to visualize their assembly process, for now we have shared how different parts are attached and welded, but there will be more. You’ll be manufacturing the robots circuit boards, batteries and many other things. And putting it all together will be part of the assembly lines.

As the final step you get to paint your robots, you can even select different colors for each part.


[h3]Gameplay[/h3]
I’m sure many of you would like to know how the game mechanics actually work, so let us have a quick look at that too. You start with, for lack of a better name, the “start building” of the assembly line, at which the initial robot part (the torso) gets hooked onto the overhead rails. From here on you build those rails like conveyor belts, they can go up, down, left, right and there are even mergers and splitters. To add parts to your robot you need to bring them to an “Assembly Line Assembler” at which you can select what action it should execute.

You are not forced to build your robots in a fully linear way, so you get to pick the order of assembly. Of course there are some limitations, it’s hard to attach a foot when the leg has not been added yet. The individual parts like arms and legs are made in regular machines like Assemblers and need to be brought to the Assembly Line by conveyor belt.

Once your robots are manufactured and painted they go into a special building. But since I haven’t disclosed why you need to build robots, I also cannot share any more information about where they are going - I surely can’t reveal everything at once :)


[h3]Steam Next Fest 2023[/h3]
Before ending this Foundry Friday episode I’d like to bring your attention to our Steam Next Fest participation. Starting October 9th there will be a free demo for everyone available on Steam.


I’m looking forward to your thoughts and feedback and I hope to see you during the Steam Next Fest,
-mrmcd

Welcome to another Foundry Friday

Hey guys, it’s time for another Foundry Friday. This week, I am your host Yog(Cheerio). Today we’re going to be talking about changes to the in game map to help you keep track of the new resources deposits that you can discover in Foundry:

Previously on Foundry Fridays

On a previous episode of FF, we showed the new ore veins that you can discover by scanning the world:



There are also more ore patches to be found below the surface:



But now that we have all these cool things to find, we need a way to keep track of all these valuable discoveries.

Map Improvements

Coming across a new resource deposit is great but sometimes you’re in the middle of untangling a big ball of spaghetti and you want to keep track of your fancy new discovery for later. This is where the new map features come in.

The first thing you might notice is there are now map layers on the right side of the map. So even though we’ve added a lot more information to the map, it’s always possible for you to turn off any information that might be in your way:



The next thing you might notice is this outline which represents the scanned areas of the map:



This represents the areas that you’ve scanned with your scanner.

As you scan more of the map, any resource deposits you come across will be displayed with an icon:



Sometimes, you might scan an area, there might be resources in the area that can’t be scanned until you unlock the appropriate research. In these cases, you’ll see the approximate location of the resource:



And then finally, once you unlock the appropriate research, the resources in these areas will be revealed without having to go back and rescan the area:

In Summary

Hopefully this gives you a glimpse of one of the tools available to you when exploring the world of Foundry. If you have any thoughts, please come join us on our discord.

Once again,
Thanks for listening!

First-person games like Foundry often face a common problem: How do you accurately render the player's gun—or in our case, drill—in front of the camera? The drill should follow you wherever you go and receive correct lighting.

[h2]The Naïve Solution
[/h2]
The naïve implementation involves simply "parenting" the drill to the camera so that it follows you around and appears to look correct. However, what happens when you get too close to a wall? Since the drill exists in the world, it goes right into the wall, causing an issue known as clipping.

Oh no! That drill doesn't look right

[h2]Solved Problem[/h2]

Don't worry—this is a solved problem. We've all played shooters and seen the gun displayed correctly when up against a wall.

Random Wikipedia CSGO image

Some modern AAA games tackle this by rendering the first person in world space, using IK or other animation techniques to have the hands pull away when you're against a wall. This makes sense for first-person shooters when shooting doesn't make mechanical sense. But in our game, we spend a lot of time up against a wall, drilling!

The more common solution for ensuring that the first-person elements are always on top is to use two cameras: one to draw the world and another to draw the first-person elements. This guarantees that the drill is always rendered above the world. An added benefit is that each camera can have different field-of-view settings, ensuring that the drill doesn't look distorted on ultra-wide monitors.

Rendering and compositing

[h2]The Catch[/h2]

So, let's try that, shall we? Perfect, it looks great.

Well, if only things were that simple. Foundry uses something called "deferred rendering" (which we discussed in more detail in this previous post) through Unity's "default" rendering pipeline. Drawing with two cameras requires running the entire pipeline twice, resulting in unacceptably high performance overhead. Even if we run the second camera in forward mode, we still couldn't reduce the overhead to acceptable levels. It was adding as much as 25% overhead to our frame time, resulting in lower frame rates across the board.

So, we need to creatively solve first-person rendering within a single camera, using a deferred rendering pipeline.

[h2]Time to Get Creative[/h2]

To do this, we simulate drawing with multiple cameras within a single camera setup, even when dealing with complex multi-object first-person geometry.

First, we render all first-person objects into the "stencil buffer," a special buffer that allows us to efficiently mask out areas in the image for future draws. We also draw the depth at this point, with "ztest always" set, ensuring that these meshes are drawn regardless of their position in world space.

Stencil buffer after drawing our drill

After filling the stencil buffer with first-person geometry, we draw the color data. We first verify that we have the correct first-person stencil set, and then check if the depth in the depth buffer is "zequal." If that's the case, we draw.

Depth for the drill is also drawn, regardless of if the drill *should* be inside a wall

One final issue remains: World Space UI actually draws after all our geometry, so we need to handle that as well. Unity UI includes a special component called a "Mask," which prevents child elements from drawing outside the graphic. Here, we apply another custom shader to check the stencil mask from before and determine whether we should draw the UI.

Reusing Unity's UI masking system

After all this, we had more masking and positioning work to do for forward-rendered objects like smoke and wide-aspect monitors. But the solutions largely follow the approach we selected, so I won't delve into that here.

Tada! It works, and it's fast

[h2]In Summary[/h2]

Developing games is a mix of best practices and creative problem-solving. Every project will have its technology limitations. Instead of lamenting the high costs of compositing two images in your engine, your job becomes finding a solution with the tools you have.

-MarkL

Hello everyone!

It’s me again, mrmcduck, with another FOUNDRY FRIDAY episode. Today I am talking about the most common machines in the game: Loaders. First I want to talk about them in general and then we take a look at a recent change our team has made.

[h2]Let’s talk Loaders[/h2]
Loader, Inserter, Sorter. There are many names for the key element in factory games: The thing that moves items between belts and other machines. Some games even come without them at all and some variants have more features while others have less. Even though there is the obvious commonality, there is also a lot of nuance in how the Loader can be designed in terms of a gameplay perspective. Here I’ll share my personal thoughts about the different variants and where I see the pros and cons for our first person 3D factory game.

[h3]Loaders or no Loaders?[/h3]
The biggest question first: Should there be Loaders? They could be removed if all machines have had input/output connections for belts so that belts can go directly into or come out of the machine. For FOUNDRY I decided that this is not the way to go, and here’s why.

Benefits:

• Having one less buildable object makes the game more streamlined, which is in most cases a good idea, it’s easier to understand.
  
• It
• might* look better, I think this depends on how both variants are implemented, but in general there is a good chance that this is going to look better.
  

Negatives:

• If you want to supply a large amount of machines it takes a lot longer to set up everything necessary because you need an additional splitter per machine (to branch off your belt into each machine). Splitters tend to be large and it requires more complex builds if there are multiple inputs and outputs. Also it requires more slopes to bridge the mess of belts that starts to exist on each side of the row of machines. With Loaders of different ranges it’s easy to build two or even three parallel belt lanes next to a row of machines and connecting them is fairly simple. For player comfort we always aim to require the least amount of clicks possible to build what is needed.
  
• Cannot do Filter Loaders where only a certain item is taken from the belt. It could alternatively be achieved with a filter splitter but that gets cumbersome quickly if you need multiple.
  
• Loaders have more flexibility, for instance you could have two belts with the same item and connect them both to the same machine so that items are taken from whatever belt has items available. While this example is certainly not the most necessary thing, the general argument holds up, especially for more experienced players and complex builds.
  
• All recipes will have to look the same in terms of amounts of inputs/outputs per machine type. Alternatively you could have a machine with 4 inputs and 4 outputs and only the ones needed would be used, but that isn’t great either.
  

[h3]Loader Throughput Speed[/h3]
Many games have multiple Loaders with different speeds, providing an additional gameplay element of figuring out which or how many Loaders are necessary. So far we went with an extremely fast Loader speed which is always enough to satisfy the machine requirements. The reason is that building in first person is more time consuming than in 3rd person and forcing the player to build multiple Loaders per machine per same item type seems like it could backfire quickly. However, it’s something we’re still evaluating and maybe at some time FOUNDRY will have different Loader speeds.

[h3]Machine to Machine & Belt to Belt Connections[/h3]
Some games have Loaders which can be used to connect two machines or even two belts to each other. I think this is a good feature as it allows for more flexibility and more advanced designs, yet I decided against it in FOUNDRY. This time the reason isn’t that there are gameplay related negatives, but that it’s hard to come up with a visually appealing design in a first person 3D environment that is capable of achieving that. The only design that works would be the Factorio-style rotating arm that grabs items from one side and puts them to the other side. That specific design has a few problems I’m going to explain in the next paragraph.
Additionally I think it is more of a niche feature. Most players will rarely use a machine to machine setup as they are only rewarding in extremely advanced (ultra-high-throughput) designs where belt speed becomes the bottle-neck.

[h3]Identifying issues with our Loader design[/h3]
After some testing and feedback we realized that the fully obfuscated belt tile beneath the Loader is not great and needs improvement.

First, here are the reasons I initially went with such a design:

• Items can be placed on / taken from anywhere on the belt tile below, not just the exact center of the belt. This makes it tricky to simulate like a rotating arm (or other things that grab items) to be at the correct position. There are ways to solve or lessen the issue, but they all come with downsides, be it gameplay-wise (messing with throughput ratios) or visually (like heavy clipping into other items or jumping items). I’m fully aware that my explanation is not sufficient to lay out the problems, but the topic is so complex it could fill its own blog post - so I’ll just leave it with that.
  
• Items can be squeezed into gaps that are too small for a full item, causing them to overlap for a brief period. The moving belt automatically unfolds those overlaps. The reason we do this is that it’s necessary to achieve maximum belt throughput, otherwise those gaps would never be filled and cause unreliable belt throughput ratios.
  

Now let us look at the problem our design caused. There are few smaller ones like mediocre visuals and sometimes less than ideal visibility, but there is one core issue we consider close to game-breaking: If there is an input Loader at the end of your belt it is impossible to find out what is beneath that Loader. And in case of a wrong item being there, it is impossible to figure out why it’s not working. Most people experiencing this expected the game to be broken. See the picture below:


The machine is configured to take Xenoferrite Plates to craft machinery parts, but it’s not working at all. On the picture on the left everything seems fine, however once you remove the Loader you see that some other item that shouldn’t be there was blocking it. Unless you demolish the Loader, this is impossible to figure out.

[h2]New Loader Design[/h2]
To address those problems we redesigned our Loader. It’s not a huge change since we liked the general look and style, but we wanted to open up the visibility. So here is it:

[previewyoutube][/previewyoutube]
The biggest change is that we can now see into the Loader, which makes understanding the factory a lot easier and solves our previous problem. The open space now features a teleport effect that gets more intense after an item has been moved, giving visual feedback whenever a Loader moves an item.
We did an overall pass on the visuals but kept the general shape and look. It now features arrows on top making it even more obvious if it’s an input or output loader.


But did you spot the biggest change? The belts aren’t as high as they were before. We did this to be able to reduce the height of the Loader, which makes the factory feel a lot better. The Loaders don’t obstruct machine and screen panel visibility as much as they did before. But it turns out that lower belts itself helped dramatically with what we tried to achieve: They are less often in the way now, stepping onto them is less jarring as the step up height is smaller and you see more of your machines and factory.


So what about the problems I tried to conceal with the closed design? Yes you get to see items disappear or pop up inside the teleport effect, but the visual effect breaks it up nicely and doesn’t make it feel weird or unfinished. In future we might look into polishing this further with adding a fade effect to the item itself.
Overlapping items: It’s almost impossible to see when the belts are moving, and if they are not and an item gets squeezed in it’s just something to accept. It’s rather rare to spot and the overall benefits outweigh the rare visual inconveniences.

We’re looking forward to hearing your feedback and thoughts around this change. This concludes today's episode of FOUNDRY FRIDAY and see you again in two weeks!

-mrmcd

Hello everyone!

It’s time for another Foundry Friday post. Today I, mrmcduck, will talk about what I’m currently spending most of my time on: Content. A word everyone knows in relation to video games, but what exactly is content?

The way I see it, a video game is mostly split in two categories: Mechanics & Content. Put simply, Mechanics define the ruleset which can be used to create the content.

Examples for mechanics in FOUNDRY would be big things like our building system, the power system, how crafting recipes work, the conveyor belt and loader system but also smaller things like personal elevators, scanning for ore or the jetpack.

While content on the other hand is simply coming up with all the machines, items, crafting recipes and trying to balance them in a way that makes it a fun experience to play.

In particular my work has been revolving around two different tasks:

• Reworking & polishing the old content.
  
• Generating new content.
  

So let’s have a look at those two tasks!


Why I generate more content is pretty obvious, but you might wonder why am I reworking some of the existing content? Our game was available for a while in a pre-alpha state and our team was able to gather tons of feedback. This feedback helped us identify where our content had problems and where it worked fine. I have been tackling the areas where our content needs improvement. Here are the key issues we identified, sorted by severity.

[h2]Too many mechanics introduced too close together[/h2]
Many players got frustrated by the pacing of new mechanics. Sometimes the game dragged along where you had to build up lots of regular building chains (going through content), and then it suddenly introduced a lot of mechanics at the same time, here’s our worst example:
Producing steel required Ignium, something that could only be found deep underground, so the game had to introduce personal elevators, freight elevators, underground mining and new machines (the crusher) at the same time. On top of the complexity it also took a long time to build that all up before you get a reward.
Another, albeit a less drastic example would be our game start where low voltage and high voltage power were introduced very closely together, causing confusion for some players.
So what I am trying to do is spread the introduction of new mechanics into similar paced intervals, providing a less frustrating and more entertaining path through our content.

[h2]Overly complex or expensive recipes[/h2]
This one is easy to explain, some things were just a little excessive in complexity, meaning it took a very long time to build up its production lines. For recipe complexity it matters that there are rewards in regular intervals:
Let’s say the recipe to craft Steel is complex, but as soon as you are done you unlock new buildings, giving you a reward as soon as you gain your first Steel. Later on the recipe for Machinery Parts requires Steel and on top of that is additionally complex for other reasons, that is fine too as the steel production is already built up.
However let’s assume the recipe for both Steel and Machinery Parts is unlocked at the same time and there is no isolated use for Steel, that would mean you have a very time consuming task just for the Machinery Part production. It would be way more frustrating because the time spent before a reward might be too long.
This might seem more of a perfectionist problem to solve, and while it partially is, such things are not to be underestimated in regards to the players feeling while progressing through the game.

[h2]Limited ingredient or machine usage[/h2]
Some items and machines had very limited use, with our redesign I plan to be more conscious about not having machines that only do a single task. This fortunately gets easier as the overall content amount increases.

[h2]Minor Changes[/h2]
I’m not going into full detail on this point as it would end up in a long list of short problems, but there is a lot more to polish than the mentioned points above. I’ll provide a few examples:

• I tried to create a better onboarding experience by making sure the first hour of the game is easy to understand.
  
• Certain things got simplified, f.i. having four different ways to make Xenoferrite Plates was just too much.
  
• Other things got more depth, f.i. a boiler and turbine setup for power generation instead of a single generator machine.
  
• Some technologies were moved, f.i. solar panels are now only unlocked much later. While they seem like the obvious choice for easy to use energy at start, most people just had an extremely frustrating first couple nights with powerless factories.
  
• Lot’s of balancing changes, especially recipe costs: Let’s face it, waiting until conveyor belts and building blocks (foundation) are crafted is no fun, I made both really cheap so that you don’t feel constrained in your creativity.
  

Most of our existing content rework is done at this point, the result so far? The initial hours of the game feel a lot better and should provide a more coherent gameplay experience. The pacing behind the introduction of new mechanics is more evenly spread and the next reward isn’t far away in most cases. It’s worth noting that a lot of improvements have been made by adding or modifying mechanics, but this is not the topic of today's Foundry Friday post.


So let’s have a look at what you all want to know most: What’s new and what’s coming at the mid and endgame?
We already announced the Assembly Lines, a feature where we visualize the manufacturing process of various end products. We continue to stay silent about what the end product you’ll be making is, but I can tell you the following: It’s high-tech and it has lots of room for different variants. Given that, we are going to venture into production of typical high-tech products like advanced electronics (processing units and alike), specialized metallurgic goods (precision parts) and other things required to create high-end sci-fi products.
Expect ores, machines and production methods around such a theme. We will also continue to expand on heavy industry with large buildings like the blast furnaces.

There are endless details I could go into, but I will save this for another day's blog. Instead of that I want to conclude with a little insight on how I come up with new content.

[h2]Content Generation[/h2]
Coming up with new content can both be easy and super tricky. And it’s different all the time, depending on so many variables and circumstances.

When I work on coming up with new content I try to combine the following requirements:

• Sticking to my vision for the game and what it should be about.
  
• Keeping in mind which game mechanics are available, need to be introduced or need additional content.
  
• Making sure the player will have a positive experience progressing through the content.
  

Most of the time those three things fight each other. Sometimes the vision is way too ambitious and the mechanics don’t support it, or sometimes the mechanics do support it, but it won’t be fun at all for the player. Sometimes you have the almost perfect mix of content and mechanics, but it seems like it simply doesn’t fit the narrative.

Here’s an example, one of the key mechanics in FOUNDRY is our Minecraft like voxel terrain system, therefore we want it to appear early, showing players how our game is different to competitors. So this would count as the 3rd point, we know what player experience we are aiming for. But introducing elevators and complex underground mining mechanics after just an hour of play time? Very bad idea, doesn’t work at all with the 2nd point. Those advanced technologies should also require steel instead of metal, so the narrative (the 1st point) isn’t matching either.
I solved this by changing the depth of the first underground ore vein, so that it can be reached with regular drilling instead of requiring advanced technology. Now all requirements are met. This may sound like a trivial task, but such things often take days of iteration and playtesting before you finally figure it out!

But that example was extremely mechanics-related, so let’s have a look about how I generate content that isn’t so heavily constrained by mechanics and player experience. Right now I’m working on our oil-equivalent called Olumite and how it’s processed into other goods. Here I just want to create an hour or two of playtime, so I need to come up with items, liquids, machines, crafting recipes and a science unlock progression.

I tend to start off by gathering information about real-life equivalents. Even if our game is sci-fi and I could make up whatever I want, I firmly believe that things feel better if you have a loose connection to what could exist in reality. It makes things easier to understand and remember as you can relate to it, otherwise you would be forced to remember my made-up thing. While working on FOUNDRY I read hundreds of articles about industry, manufacturing and material science just to get a feeling about such things.
Once I have the understanding of how it works in reality I try to adapt it into what makes sense for our game, I do replace certain parts to mix things up and to make it closer into what fits the gameplay loop. In my head there is a lot of (basic) lore about ore types and what characteristics they possess and why our crafting recipes ultimately make sense (mostly!). One day I will add that information to our info database.

From here on I lay it all out in various internal tools, mostly charting software where you can quickly visualize production chains and progression trajectories. During this step I evaluate a lot, make sure it’s neither too simple nor too complex, trying to avoid all the pitfalls I wrote about above that made content reworks necessary and most importantly of all I try to create something that feels cool and entertaining. There is no specific process on achieving this, I just try things until I’m happy with them - often I do this while going for a walk.

Once I’m happy with what I see in my charting software I add it to the game and build it once to see how it feels. And only after that I start looking at the actual numbers like input/output item count, machine speed, science costs,... For all of those I have custom-written software to assist me, for example showing how certain machine speeds match various conveyor belt speeds. Getting the numbers right is one of the hardest but fortunately also most forgiving parts of the process - it’s easy to modify and tune afterwards, also it’s not a disaster if some things don’t match perfectly. I try to create machine speeds and ratios that add up nicely, but it’s never possible to come up with numbers that work all the time in any case.

The final step of creating content is doing several independent internal playtests to ensure it’s all ready for a wider audience at the experimental branch.

I initially planned to write a way shorter post but it looks like I got carried away sharing what I do most at the moment. I enjoyed shedding some light into a topic most developers rarely talk about and I hope you have enjoyed reading it.

This wraps it up for today's FOUNDRY FRIDAY post,
-mrmcd