Read this post on our website,Factorio logo patches (Jitka)
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.
Sound design (Ian)
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.
[previewyoutube][/previewyoutube]
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!
Animated trees. Of course (Albert)
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.
https://cdn.factorio.com/assets/img/blog/fff-324-animated-trees.mp4
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 leafs, and the result of this experiment was fantastic.
The rest will be explained by Allaizn himself.
Tree shader integration - you probably forgot something if it works on the first try (Allaizn)
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:
- High vs normal resolution textures.
- No, high, or low quality compression.
- Full or half color depth.
- Leaves decrease in amount due to pollution damage and have a total of 4 stages.
- Leaves desaturate with rising amounts of pollution.
- Trees can be rendered as part of the game world, or as part of the GUI.
If you disregard counting the desaturation, there are thus 48 different ways to render the same tree sprite, and we of course want all of them to work, leading to me being stuck hunting for the missing cases for a few days.
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:
https://cdn.factorio.com/assets/img/blog/fff-324-tree-debug.mp4
The three color channels encode the three main properties the shader has to work with:
- The red channel reports the displacement in the horizontal direction - no red means displaced in one direction, full red in the other.
- The green channel reports the same for the vertical displacement.
- The blue channel reports how much the distortion has to be scaled by in order to account for different texture resolutions - full blue results in no scaling, half blue in a scaling of 0.5, no blue results in no distortion at all since it's scaled by 0.
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 leafs.
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 atlasWhen 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.
Optimizations (Rseding)
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:
- Each tick; check if the inserter has a burner energy source. If it does:
- Check if the energy source is completely empty and go to sleep if so (no fuel, can't move fuel into itself since it can never move).
- Check if the item in the inserter hand can be used as fuel for this inserter. If it can:
- Move the hand towards the inserter itself.
- Each tick; check if the destination has moved away (teleported/vehicle drove away).
- Each tick; check if the source has moved away (teleported/vehicle drove away).
- Each tick; check if the target or source is marked for deconstruction.
- Each tick; check if the source has changed force.
- Each tick; check if the enabled condition exists and if the inserter is disabled by it.
If all of that passes, then move the hand towards the source/destination position.
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.
Targeter driven eventsTargeters are a thing we created and have refined over the years for 2 main reasons:
- They're disappear-aware pointers; when the thing you "target" is deleted, your pointer is cleared (set to nullptr).
- They're saveable/loadable pointers; you can persist a pointer through save -> quit -> load.
Most things in the game that need to "point" at something else will use these (with a few exceptions of course). Inserters use these. My idea was fairly simple: anything which can be "targeted" can go over anything "targeting" it and let it know when some rare event happens (everything the inserter had to check for and some others). The events aren't free - but because these cases don't happen commonly the inserter not having to do these checks makes the cost of the events when they do happen meaningless in the overall performance charts.
SnowballingWith the Inserter update logic drastically simplified and with the new Targeter driven events at my disposal I started to notice things:
- Mining Drills share most of the same checks that Inserters do - so they got the same treatment.
- Locomotives, Cargo Wagons, and Fluid Wagons had the same kind of checks; so now they don't need to be active in 99%+ cases.
- The blue triangle module-requesters had the same kind of checks; so now they don't need to be active in 99%+ cases.
- Logistic and Construction robots had the same kind of checks for (did the target move?) so now they don't need to check that.
After finishing with those I re-profiled and with those entities taking far less time different interesting things started showing up:
- Burner energy source logic was doing several slow checks for the edge-case behavior.
- Transport belts were doing a O(N) check every time they would move items when it could be done in O(1) time.
- Anything which made smoke from consuming energy was doing several slow checks to try to make smoke when they didn't need to in most cases.
And finally one last thing showed up: heat pipes. Every time I make something run faster something else takes its place in the "what is time spent on each tick" (this is expected), but it also means it reveals new things I might not have noticed before.
Heat PipesThe 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.
ConclusionElectric 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.
Please note, the number of commits does not reflect the value and quality of an individual :).
