FOUNDRY News

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

Foundry has been undergoing some massive changes over the past few years, bringing on developers from across the industry to create a unique factory game like no other. Myself (MarkL) and Cheerio were previously at a game studio called Klei, where we regularly worked with traditional animators and artists from the world of television cartoons. I thought for this Foundry Friday I would share some secrets they taught me, and what I find to be the most useful curve in all of game development.

Traditional animation training can impart numerous lessons, including Disney’s famous “Twelve Principles of Animation”.

Foundry is very much not a Disney cartoon, but many of these principles are still useful. We have examples of most of the twelve principles in Foundry, but in this post I chose to focus on the ones I, as an engineer/designer, reach for the most. After learning about these principles in Foundry you may start to see them in many of your favorite games.



Many 3D animation packages use this curve on movements by default. This creates a more natural motion because it mimics the need to accelerate and decelerate. But there is another place you will find this curve, in graphics!

The shader function: smoothstep()

If you were to peruse the Foundry code base you would find this function used liberally. It’s a great way to create a visually pleasing falloff or blend. Recently I have been working on a new grid visualization shader to help you place objects, and as the grid approaches an edge we use the smoothstep to blend it off, instead of a jarring hard cut.



Searching through Foundry’s shaders it looks like we have used this to “smooth things out” 103 times, from lighting falloffs to chroma keying.


Now on to my absolute favorite curve and animation curve of all time. This curve will come in handy no matter what you are working on and make everything feel more “intentional” and exciting.



We have placement helpers when building objects that we need to show, let's first take a look at linearly scaling them in and see how that feels.

I slowed the animation down so it shows up on GIF better

That feels cold and mechanical. Now what if we apply that exaggeration curve?



Now it feels more Impactful, playful and intentional! Truly the easiest improvement you can make to any linear animation. This is the first curve I reach for in Foundry whenever any animation doesn’t feel “right”. Heck, here it is when displaying UI options:



This almost cartoony exaggeration feels pleasant and playful. It’s such a simple concept, a curve that goes a bit too far and comes back.


I feel like the curve is basically communicating to the user that "hey, we mean to be doing this thing". With that knowledge you can now apply these curves in reverse, like when we remove things.

Reverse exaggeration curve

When objects or terrain shatters we despawn it over time. Previously we simply popped it off, but that was jarring and unpleasant. Here I've added a despawn over time AND an immediate despawn when the objects get close to the camera, so they don't clutter your vision.



The effect is subtle, but satisfying.


Video games (even 3d ones) can borrow a lot of cartoons and traditional animation. There is no reason the to reinvent the wheel. When you look outside your own "bubble" you can find helpful lessons that might apply in your situation, even outside of games.

Cheers,
-MarkL

Hello! My name is Jason, the art director of Foundry. I have the honour of writing this instalment of our ‘Foundry Fridays’ dev diary, a place for different members of the Foundry team to share what they’ve been working on. Today I’m going to talk about smoke VFX.

But wait!! …before we dive into that, let’s first talk a little about our art style.


If you’ve been reading our previous dev diaries and seeing our recent posts on Discord, you can see we’re going with a stylized look for Foundry. Considering we have a procedurally generated voxel world, we felt a stylized look was best suited for our game.

But how stylized?!

If we looked at a spectrum with a “photoreal” look on the far left and a “very stylized” look on the far right, we’re targeting something that’s somewhere in between, but leaning more towards stylized.

Our art style can be described as ‘soft, vibrant and cleanly illustrated’. The weathered, chipped edges of metals on factory machines are ‘clean’ rather than ‘dirty’ with grunge and high frequency noise. Biomes provide a soft and welcoming backdrop that contrasts nicely with the heavy, bulky, industrial look of the factory machines. The ‘clean’ and ‘illustrated’ look is what unifies everything together to create a cohesive and consistent art style across the game.

The world of Foundry should be a place you want to stay and play in for hours and hours.




As with all the other visuals across the game, we wanted to create a look for our smoke VFX (along with all other VFX in the game) that fit nicely within our art style. Smoke is obviously a big part of the visuals in a factory building game, so we wanted to put in the effort to come up with something very appealing to look at.

Our first attempt was leaning a little too far into the ‘very stylized’ end of the spectrum. It was a more 2d animated look that you often see in cartoon anime. Although moving in the right direction, it looked too flat and felt a little disconnected from the other visuals in the game. Here’s what that looked like…

[previewyoutube][/previewyoutube]
We then came up with a look that brought a little of that 2d animated look and combined it with soft, fluffy, thick volumetric shapes. So delish - I wanted to eat it like cotton candy. By using normal maps as well, we were able to get our directional sun and moon light to highlight the puffs of smoke. This gave it even more shape and made it feel part of the surrounding environment with our dynamic time of day lighting.

[previewyoutube][/previewyoutube]
This brought joy to our hearts 😄

The smoke now felt part of our stylized world and also felt unique and signature to Foundry.


Finding an art style is often a daunting task. It takes A LOT of iteration and fast prototyping to finally achieve the direction that's right for the game.

Our stylized smoke is just one part of the overall aesthetics of the game and is serving as a guide for all VFX in Foundry.


I hope you enjoyed this Foundry Friday. As always, if you have any questions, please hit us up on Discord.

Thanks for reading!