We would like to introduce our new fabric Factorio logo patches, which are now available at our e-shop. These sew-on embroidered patches are ideal for clothing, hats, backpacks, etc. The dimensions are 2.5 x 12 cm.
As we are uncertain how large the demand for these patches is going to be, we have only limited stock available at the moment.
Please note that our online store ships only once a week every Wednesday, and it is highly possible that the orders placed now will not be delivered before the 25th or December, this applies especially for orders shipped outside of Europe.
I have been brought on to Factorio to finish the sound for the game for version 1.0. It was felt that a sound designer was needed to work at the Prague office to help implement the sounds and improve the audio vision.
With a desire to make some quick wins, one of my first tasks was to add the sounds of the enemies footsteps, which we felt would really make them come alive. Unfortunately it transpired that the tech we wanted to use for this (each step being connected to the correct terrain, as per the player's footsteps), was going to be too expensive for the game in terms of CPU. After all, some of these creatures have 12 legs. Remembering a similar nightmare with giant spider's footsteps on a Harry Potter game years ago, I decided to make a simpler solution. So what we now do is to play a one shot sound for each cycle of the walk animation.
First of all I started sourcing sounds from a library so I could rapidly prototype something. By taking some eggshells crackling sounds and adding them to a video of the walk animations, I managed to create something pretty good for the biters steps or movements. I plan to record some extra sounds for these later on, but for now these work fine.
The sounds are different for each enemy however, the biters have more crackle and the spitters have more of a set of thuds. The bigger the enemy, the bigger the footsteps. These sounds should give you a greater feeling of immersion into their world, as you hear them scurrying towards you just before you see them.
Regarding the other enemy sounds, it seemed to me that the spitters and biters sounded too similar and this is something I wanted to change. If we can distinguish between the sounds made by the enemies, this adds to the variety and also the fun factor. The other sound designer Val has made new sounds for spitters idles, in order to bring out their squishiness and make them more disgusting. In the meantime I've been adding these sounds to the game, playtesting and tweaking them. For example, I chose better sounds for the enemies dying, in order to give clearer feedback to the player when making a kill.
In other news, I've been busy working on mixing the whole game and improving sounds as I see fit, but I'll leave that for another time!
In last week's FFF we presented animated water as a mini-series of "small" additions on the feeling of the environment.
A lot of the feedback came saying that now the trees look pretty dead in comparison with water. We knew that in advance, and it seems like you were reading our minds because during the preparation of water we were working also on the trees. Today finally we can present this work finished.
The always running sound of wind in the game feels much better with these new animations, plus the sounds to come. The shadows cast by the trees are also animated, and it makes the effect on top of the water somehow much better.
The idea of animating tree leaves is old as Factorio, but we never had the time due to obvious other priorities. One day Tom (wheybags) came with a very nice prototype, and I got very engaged -again- with the idea. Some time after, Ernestas made a new prototype based on different techniques. That was also really interesting. The subject was moving pretty solidly but it wasn't good enough. Next, Viktor (Allaizn), had the idea of using the normal maps of the trees instead of a generic noise to move the leaves, and the result of this experiment was fantastic.
The rest will be explained by Allaizn himself.
My first "big" task was to integrate the shader Ernestas made into the game engine, which was exciting due to its looks, but also somewhat stressful considering I only rarely looked at that part of the game's code until then. The first step in doing this is usually to understand how the shader itself works, so allow me to give you a small explanation of what is happening.
The GPU renders a texture pixel by pixel, and each pixel (roughly speaking) initially only knows where on the screen it is. A shader is then necessary to give it the extra information needed to arrive at the color it's ultimately supposed to have, where it acts a little bit like a "color by numbers" game - we ready a texture as the colors to use, and also pass in some numbers that tell it which part of the texture to use (their technical name is UV coordinates). When rendering sprites we almost always want to pass in these numbers in a way that results in the texture being copied onto the screen (see the image below) - but there is nothing preventing us from messing with those numbers beforehand ;) .
Left: you see the numbers that are chosen to result in an onscreen copy of the supplied texture.
Right: the scrambled result if you just supply random numbers.
Passing in random UV coordinates will usually result in an completely unrecognizable image, but we can be more crafty than that: we can pass the number passing to the pixel below the usual one, or to the one above - and if we do that strategically, the image looks like it shifted a bit. Vary this shifting in time, and the result is the appearance of slight movement across your image! This offsetting by a pixel or two is called distortion, and it's usually supplied to the shader by a second texture (whose color values we just reinterpret as the shifting values we need) called the "distortion map".
Back to to the implementation side of things, it was surprisingly easy to arrive at a working version since I could copy the hardest part (the shader itself) straight from Ernestas prototype - only to then realize that the title of this paragraph is almost always true! Trees can be drawn in surprisingly many ways:
During that time not everything went smoothly: sometimes everything seemed right with the code, but the trees seemed to refuse to move. There was thus always the question whether the effect was active at all, or if it was, then how much it actually did. This lead me to write a debug visualization into the shader:
The effect is sped up a bit to make it easier to see.
The three color channels encode the three main properties the shader has to work with:
The title theme also struck me in another way: the effect depends heavily on the provided distortion map, and our first version resulted in a look that was best described as "it looks fine if you turn it down until it's nearly invisible" - even the best implementation in the world just doesn't matter if the final effect doesn't look great, too. Given that the initial distortion map was mostly noise, I instead tried the very opposite approach: find a texture that is highly correlated with the tree leaf texture and use that instead - ultimately settling on the normal map of the tree leaves.
The shader itself uses only the red and green channels of the normal maps, which made them a fine target for BC5 compression that we haven't had use so far in the game (see FFF-281 for more info on compression). After an astonishingly short time, the compression was up and running - or so I thought, since I was once more struck by "did you think of this?". The culprit this time was mipmapping, which wasn't aware of the compression and thus downscaled the compressed image instead of decompressing, downscaling, and recompressing again.
Normal maps as seen in the sprite atlas
When the project was nearly done, I was hit one last time by the realization that I forgot something: moving tree leaves should result in their shadows moving too, right? I thus spent a little bit more time to implement a special shader for them that does just that by using generated noise instead of a distortion map.
There are a few key parts of the codebase that end up being "slow" relative to everything else and the reason why almost always simplifies down to edge cases.
"Why is ... so slow?" -> "Because it has to check for A, B, C and D each time it does any logic". "Why? Those almost never happen" -> "Because without the checks, the logic is simply wrong".
About 3 years ago I had my version of this with inserters. Inserters end up being one of the more common entities for the simple fact of: you have to have them if you want anything to run. However, inserters are also one of these "slower" entities where the basic idea of what they do seems so simple; "how can moving items from A to B in an arc end up so slow?" (relative to everything else of course).
And so I looked at the profiling results and the code it pointed at:
It's not surprising that ends up being "slow". But you can't just not do any of that and say "it's okay". The obvious answer to all of that stuff is "that doesn't happen frequently/those are edge cases; they should all be done through events". But then - how? To put it simply; there was no event that the inserter could use to know when these things happen so it had to check each tick if any of them happened. I ended up leaving it alone and went back to working on other things. But it always stayed in the back of my mind; cooking - trying to find a solution. 3 years later I found it: Targeters.
Targeters are a thing we created and have refined over the years for 2 main reasons:
With the Inserter update logic drastically simplified and with the new Targeter driven events at my disposal I started to notice things:
After finishing with those I re-profiled and with those entities taking far less time different interesting things started showing up:
The first thing I noticed with heat pipes is: all of the actual logic for heat pipe flow isn't even in the heat pipe entity itself. The entity just defer the logic to the "Heat Buffer" class. It got me wondering: why even have the "update" logic go through the entity at all if it doesn't do anything? Several days later and a lot more code than I set out to write; I moved all of the update logic for heat flow into its own dedicated manager class (almost identical to how fluids and electric flow have a manager class).
It looked too good to be true; what was 0.55 ms/tick was showing 0.17 ms/tick (a little over 3x faster) by just not going through the entity each tick to do heat flow. A lot of testing later and the results were correct; it was just that much faster. The underlying algorithm didn't change but it just ran > 3x faster now by touching less memory. This is another nice example of "Factorio is not CPU bound, it's memory latency bound". More cores wasn't going to make this faster - because it was never limited by how fast the CPU ran.
Electric networks... Fluid networks... Heat pipe networks... none of these interact with each other or anything outside of themselves. What happens if I just update all 3 in parallel? Not surprisingly; each of them got slightly slower (because they are competing for memory access) but overall it was still measurably faster. The interesting part about this though: 1 of the 3 always takes significantly longer to finish than the others. That means that the others end up being essentially "free"; the game has to wait for the slowest to be finished anyway so the faster 2 of the 3 get a "free ride" to finish long before game finishes waiting for the slowest to be done.
Every save file I've tested ended up running measurably faster in the end. The most extreme one (lots of steel furnace based smelting) showed a 2.3x speed-up.
As always, let us know what you think on our forum.
