Factorio News

Read this post on our website.


2020 is going to be quite an exciting year for us. We have our 1.0 date set to the 25th of September, and there is a lot of preparation to do.

It is no doubt to any of us that we would not be able to have any success without the great community that has developed for the game over the last years, and the support of all our players and fans.

As is almost tradition, Albert has prepared a commemorative postcard/wallpaper to celebrate the last FFF of the year.



Here's to a great year to come!


I had few months of "vacation" from work by playing world of warcraft classic and generally getting some distance to be able to help with the finishing of Factorio with some perspective and a clear head. Now I have returned from the lands of Azeroth, back to work with fresh mind to finish what is needed - hopefully.

In this time, I was thinking about games in a bigger perspective. I have seen and admired videos related to game creation subject like A Love Letter to GOTHIC's Open World Design, Bethesda's game design is insulting, The decline of Gaming and the unbelievable story of the Fallout 76 fails that goes way further than I thought it can.

And then I played our new tutorial again and realized what we did. We found something very close to a local maximum. To start from the beginning: The whole goal of the new tutorial introduced in 0.17 was to explain Factorio to the wider audience. To make sure, that even someone who wouldn't normally play the game would understand the concept and would automate. The motivation was partially due to the fear of someone playing the tutorial who just doesn't automate on their own. That someone would miss the idea of the game and would had completely wrong perception about the game. For example, that someone would play it only for 30 minutes and would think it is just about endless grinding and manual crafting, and they would never experience the automation midgame which is where the game starts to shine.

This was a noble goal, but we didn't realize all the costs we had to pay for it.

To make sure that the players know how to research and use assembling machines, and they get to experience that part of the game fast enough, we had to force them to do it early on. Firstly, this breaks the progression, which is one of the cornerstones of Factorio game design. The progression in the beginning is roughly this:

Manual Mining -> Automated mining -> Automated logistics -> Automated production & science.

The order of the progression is very important, as in every step you start doing something new that you had to do manually before, so you appreciate the upgrade. Also, when you are starting, you are exploring the game mechanics in the logical order and understand the motivation for those. This is in clear contradiction with forcing players to use assembling machines in the first 5 minutes of the game.

Long story short, there was no way of just tweaking the new tutorials, the fundament on which it was built was wrong. Luckily, I wasn't the only one feeling that way. So I had to do the very hard thing, and telling the people that worked on it, that we are scrapping it, and in 0.18 we will switch to using the old tutorials again. They are way less polished with lower production value, but these things are much less important than the core gameplay mechanics as far as I can tell. We plan to tweak several things in the old tutorials, but the structure is planned to be kept the same.

This is definitely a lesson for the future.


It has long been on the horizon, and the Christmas gift giving has given us that last push, for us to reach 2,000,000 sales. I would say its quite an achievement for a Indie game that has never been on sale.

We first hit one million sales in May of 2017 (FFF-192), so its been about two and a half years to sell another 1,000,000 copies. I wonder how long till three million... Any bets?

I find it quite interesting (and not surprising) to look at the proportion of the sales that come from each of our distribution channels. As you can expect, Steam accounts for the majority of all copies of the game sold.



What is also interesting, is that we had a lot more sales on our site before we launched on Steam. Either this is Steam cannibalising our website sales, or just everybody who wanted to buy it on our site did so before launching on Steam. Another data point for speculating on, is that 81.3% of people who purchased the game on our website, redeemed and activated their Steam key. Factoring that into the above numbers, about 96.7% of all players own the game on Steam.

When we reached one million sales, we threw a party to celebrate. We're not going to do the same this with this milestone, but we are thinking of having a party to celebrate the 1.0 launch next year. Any news of that will of course be communicated in the usual way.

As always, let us know what you think on our forum.

Read this post on our website.


Rseding's recent optimisations of the particle system (FFF-322) made particles much more lightweight thanthey were before, but it still left particles as rather complex beasts. A quick summary of the possible actions a particle can make during it's update:

• Move their own position.
• Advance their animation to another frame.
• Land in water and apply a trigger.
• Apply another trigger with a certain frequency.
• Remove themselves from the game world once their life time ends.

What makes this complex is that triggers are general purpose systems that can do all kinds of things,including creating and destroying entities, fire, smoke and other particles as well as playing sounds or recursively applying even more triggers. In other words:applying a trigger is an "anything can happen" situation and thus totally unpredictable, which in turn makes optimisations extremely hard.

[h2]The particle emitter[/h2]
The base game and most mods don't use particularly crazy triggers when creating particles - the goal is usually to just spawn in a bunch of small animated texturesand make them fly around on screen (which is somewhat ironically what is usually called "particle"). An idea for further optimisations of particles was hence to createa kind of "simple" particle, which couldn't apply all kinds of triggers to allow handling them in bulk, which is usually faster than handling them individually.This bulk handling would be done by a thing called a "particle emitter", whose whole job is to create, update, draw and finally destroy the simple particles it manages,with the idea being that a biter dying wouldn't have to spawn hundreds of particles, but only a single/few emitters.

But this is not all: simple particles are not able to change any other game state, and would thus only get updated to maintain their own internal values - mainly theirposition and velocity. A small physics exercise later the idea was born to not update the particles at all - you can compute their current position from their startingone after all! Even better: if the particles aren't ever rendered, then there's no point in creating them in the first place, so there's no reason to do that until theemitter comes into draw distance - millions of biters dying in gigantic blood fountains offscreen would thus basically not matter at all for your frame and update time!

https://cdn.factorio.com/assets/img/blog/fff-326-emitter.mp4

A visualisation of the emitter in action: the red box represents the actual screen.
Particles managed by emitters outside the screen region simply don't exist at all.

The particles themselves not being allowed to affect gamestate has another benefit: in a multiplayer game, each player only has to generate the particles theysee themselves, instead of those that are visible by anyone. This also suggests not using the emitter's update function, but it's draw one instead, which yields even morebenefits due to the draw function being called during the render prepare phase, which runs on as many threads as you allow it to have.

However, all of this doesn't just magically work correctly, and there are edge cases that need handling. For example: what happens if an emitter is created offscreen andthen comes into view distance? What happens if you save and reload? What happens if you save and reload with a mod set that doesn't have the particles defined any more? It would be very odd to see your rocket silo explode in uncountable bits, see how they fly and crash into the ground - then save and reload and see everything again because the particle effect restarted.

Handling these kinds of issues took some time and thankfully only increased the systems internal complexity marginally, allowing me to focus on expanding it's features.Currently, the following things are supported to be present on an emitter:

• Handling simple particles with individual random starting positions and velocities.
• Handling simple particle streams via normal and instant tails as shown in FFF-325.
• Handling simple particles with a smoke trail behind them (FFF-325 has some examples of this, but the effect already existed beforehand).
• Handling simple particles impacting the ground by potentially being replaced with a water splash when hitting water.

Particle emitters have two main restrictions:

• They only handle a single particle type (and technically associated smoke and water splashes). Making an assembling machine burst into metallic blobs and oil splashes would thus require two emitters.
• The particles managed by an emitter cannot fly too far away from the emitter (which itself will never move), because we need to know how far outside the draw distance to search for emitters that may want to render their particles.

https://cdn.factorio.com/assets/img/blog/fff-326-all-effects.mp4

A demo particle animation showing off all effects at once - all of these are managed by a single emitter.


Game startup time (time to reach the main menu) is just as important to us as compile time (see FFF-206). With how frequently we compile and launch the game to test things, every extra bit of time spent waiting for the game to load is wasted time.

There are 2 main parts of the Factorio startup process:

• Go over each enabled mod and collect the prototype data it defines/generates (the 'data stage').
• Load and process the sprites that the game needs to run.

https://cdn.factorio.com/assets/img/blog/fff-326-mod-loading.mp4

This is a familiar sight to those who play with a lot of mods.

In the past we made an experimental setting which would cache the loading and processing of the sprites, so we never need to wait for it when nothing around them has changed. However, the game still had the process all of the 'data stage' every time the game would start.

During normal development that wasn't really an issue - it would happen in a fraction of a second in most cases. However, as the game has grown, so has the amount of stuff that gets processed during the data stage. Additionally, for every mod enabled that has anything in this stage, the time would roughly double. Recently I started to wonder what it would take to make the same kind of caching system we have for the sprite loading for the data stage.

Since mostly the results are the same between restarts, it would mean it didn't need to do most of the work - and should be faster. After working on it for about day I had a working prototype; but it wasn't actually any faster with just the base game. Not wanting to quit just yet I spent some time with the profiler and managed to find a few areas that I could optimize and reduced the time the caching logic was spending by about half. So, it finally had some benefit for the base game (although quite small).

What I didn't expect was just how much of an improvement it was going to have for the modded case. What used to take 25 seconds in my testing took only 4 with the new cache setting enabled. The time savings gets even better as the number of enabled mods increases. The setting is still disabled by default because it's highly experimental, but if it ends up stable enough, we might turn it on by default.


This is the last FFF before Christmas, so I thought we would celebrate some of the mods which aim to create some holiday spirit in the game.
[h2]Alien biomes[/h2]
Alien biomes snowy terrain is just beautiful. In the map gen settings you can crank up the 'Cold Climates' option, so your whole world is just a cozy winter wonderland.


[h2]Holiday artillery[/h2]
We must also remember to share the love to our biter friends, this mod will lets you deliver gifts far and wide, and embellishes the Artillery Gift delivery turret/wagon with a lovely red and green paint job.


[h2]Christmas tree[/h2]
And of course, no winter factory is complete without a lovely Christmas tree.

[previewyoutube][/previewyoutube]

We wish you a merry Christmas, and as always, let us know what you think on our forum.

Read this post on our website.

Hello,
The year is wrapping up, and we have been hard at work finishing off some topics before we take our Christmas break. As you can imagine, releasing any new version of the game without a few weeks to do bugfixing wouldn't be wise, so you can rest easy this holiday period without the worry of a surprise 0.18 release.


One of the motivations behind the new optimized particle system (FFF-322) was to give our GFX team more flexibility to create special effects in the game, and specifically new explosions, without a major concern for any performance impact.

With the new system as the foundation, we have been working on adding new features into the trigger items and particle trigger effects. One such feature was to have particles spawn a 'tail' behind them. This tail looked good for some particles, but not really for others, so then we added an option to spread that tail out in a natural way. This 'Instant tail' gives the particle effect a more explosive feel, with the particles really bursting out dramatically from the source, rather than in a somewhat comical single-file stream.

https://cdn.factorio.com/assets/img/blog/fff-325-no-tail.mp4
https://cdn.factorio.com/assets/img/blog/fff-325-instant-tail.mp4
Instant tail off vs. Instant tail on.

Albert spent some time adding new specific explosions for the enemies dying. This is still a work-in-progress, but so far we are happy with the initial results.

https://cdn.factorio.com/assets/img/blog/fff-325-enemies.mp4

A nice feature we added back in 0.17 is the 'damaged_trigger_effect' on all entities. This lets each entity have a customised effect it creates whenever it is damaged. For instance with the biter, we made it create a blood particle hit effect, which gives the player some visual feedback about hurting the poor critter.

https://cdn.factorio.com/assets/img/blog/fff-325-biter.mp4

Another bit of refinement we can make is setting the effect to 'hit' at a random position inside a specified box. In the case of the Roboport, which is quite a big entity, the effect is very noticeable. We can make the random offset box any size and position we like, it isn't tied to any other property of the entity, so we can precisely tweak the effect.

https://cdn.factorio.com/assets/img/blog/fff-325-roboport.mp4

With these two in place, we can start to get a bit more specific. Dom has been hard at work the last few months creating specialized damaged effects with custom particles for every entity in the game. One example is the stone wall creating stone particles when damaged and when dying.

https://cdn.factorio.com/assets/img/blog/fff-325-walls.mp4

We can also mix and match the different particles, to better reflect the composition of the entity in the resulting rubble. For instance the rail has a mix of stone, metal rail, and wood particles.

https://cdn.factorio.com/assets/img/blog/fff-325-rails.mp4

These new effects and explosions are very much work-in-progress, and are already providing a much better feeling to the destruction in the game. Please let us know what you think, and if you have any suggestions to share. We are mindful of potential performance impacts a lot of particles could create (even with the new optimized system), so we are still looking into some even more performant ideas for the most brutal effects.


A Reddit post surprised us yesterday afternoon with the news that Factorio has reached 50,000 reviews on Steam (not including those who purchased the game from our website).



This is an absolutely huge number, and we never had any idea we would reach such a milestone when the game started as a small project just 7 years ago. Many thanks to all those who have reviewed the game.

In regards to other milestones... we might have something else to announce in the weeks to come :) .

As always, let us know what you think on our forum.

Read this post on our website,


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.

[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!


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.


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 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:

• 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 events
Targeters 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.

Snowballing
With 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 Pipes
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.

Conclusion
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.

Read this post on our website


Since the very beginning of the project, we have focused a lot in the side of the factory, providing better designs for the machines, and expressive animations that give a sense of life and credibility in this area. We put a lot of effort also in the environmental side, adding different tile sizes, improving textures, adding doodads, cliffs, trees, decals, and constantly improving the map generation for a better feeling.

But apart from biters and the factory, nothing else moves in this Factorio planet. So the environment is nice looking but it feels somehow unreal due this lack of motion.

Today we proudly present the first experiment in this area: Animated water. This animation doesn't try to grab your attention, it's just there. Slowly moving. I personally bet that this animation, with the proper sound design, will provide the natural feeling that the planet needs.

https://cdn.factorio.com/assets/img/blog/fff-323-animated-water.mp4


Animation was always one of the most powerful creative tools we have. Animation is how we communicate with our audience about functionality, it creates interest and emotions people like. So let us talk about water and how the current representation might be missing something. Some of you with an eye for detail might have noticed that water in Factorio is static. It has foam, which is static. There are also some static reflections. Due to the fact that making animated water was considered polishing, we never took the time to make an actual solution.

But now we are polishing Factorio, trying to make it as beautiful as we possibly can given our constraints. I am glad to talk to you a bit about us solving animated water!

Christmas of 2018, I decided to gift myself with solving water animation in secret. Based on past conversations with Albert the goal for it was clear:

• It had to look similar to the current water.
• Photorealism was a no no.
• It had to be super cheap for the GPU.

In the past I was experimenting with this cheap clouds shader. It used fractal Brownian Motion and only sampled a noise texture, instead of the usual approach of calculating Perlin noise. With a low iteration count, it was almost as cheap as drawing a sprite. So I started MonoGame (lovely framework) and implemented a tile-based world using the same technique for the shader, the only difference being I clamped noise values to simulate brighter and darker areas. For the noise I used our water sprite.

Original - Noise - Clamped

To save GPU power, water was drawn the same as tiles, one after another. The position was easy to solve also, I simply used UV coordinates to represent the game world position. With some trial and error, water was recreated with a moving effect.

https://cdn.factorio.com/assets/img/blog/fff-323-pitch.mp4

At the beginning of 2019, I pitched the prototype to the team. Sadly it was not really accepted mostly because of the movement. However, I sat down with Albert and talked and tweaked values to more appealing ones. After that, we basically forgot about it. Half a year passed and that solution was back on the table, I only had to solve reflections, foam, transparency, out of map transitions, and some other stuff.

Solving reflections, transparency and foam resulted in using a render target to save information for water shader. A render target is just a texture on which you can draw. Using three channels RGB, I am able to save three kinds of information. Red for reflections, green for transparency, and blue for foam. All drawing is additive to account for multiple tiles drawing on top of each other. This way we are able to add information not only for shore, but also for entities.

https://cdn.factorio.com/assets/img/blog/fff-323-layers.mp4

For out of map we updated our jelly feeling with waves on top. Basically we left the old graphics on the bottom and added animated water on top. For cutting/masking out water where we want, I used another shader that generated green waves in the water render target. Now some of you might ask why we did not use a waterfall. I mean it would look nice having a waterfall to this pitch-black hole of nothing. The reason is waterfall was the first thing we tried, and concluded that the jelly looks better and cleaner.

https://cdn.factorio.com/assets/img/blog/fff-323-out-of-map.mp4


For a long time, in order to make terrain rendering fast, we would keep an offscreen buffer with terrain that was rendered in the previous frame, and reuse it to render terrain in the current frame. If the players view didn’t change at all, we would use the offscreen buffer as is, if the player moved, we would shift the buffer accordingly, and render just the bits that were not visible before. Zooming or changing tiles in the view would invalidate the content of the offscreen buffer, and the terrain would have to be re-rendered for the entire view. But that happens only in a fraction of frames, so it’s not a big problem.

You may have noticed this optimization is incompatible with rendering animated tiles, so for the initial integration of Ernestas’ water effect, I had to force a full redraw every frame.

This created a performance issue, as the tile render prepare step would take up 3ms (almost 1/5 of total frame time) when zoomed out. Why does that matter?

The game’s main loop runs in 3 major stages:

• Update - progresses the game state one tick forward.
• Prepare render - collects the data that is needed to render the current view.
• Render - uses this collected data to issue commands to the GPU.

While game update and render are executed in parallel, neither of them can run while prepare render does (more on this in FFF-70). So 3ms of additional prepare time means 3ms less can be spent in update before the update rate drops below 60 (and I don’t even want to mention how much time it would take in debug build, I’ll just say that I’d expect a lot of nasty looks from coworkers).

Luckily, I already had an idea how to solve this. The water animation depends only on global time, and the vertex data of water tiles doesn't change in between the frames, so instead of caching the finished terrain render in a texture, we can cache the data resulting from prepare render, which we call draw orders. To make it work, we cache draw orders per-chunk, and we only run prepare render on chunks that have just entered the player view (and weren’t in the cache already).

That pretty much solves the problem of the render prepare and has some nice side benefits. First of all, changing render scale doesn’t need to invalidate the new cache, so zooming doesn’t cause prepare render to run for all tiles in the entire view. Secondly, it creates opportunities for other future optimizations - for example, we can start caching tile draw orders that are likely to enter into the view in advance and spread this work over multiple ticks, or we can generate tile draw orders for each chunk in parallel as they are independent of each other now.

Even though the water effect is relatively cheap, some of our players play the game on really weak hardware, which already struggles with the current state of the game, so we needed to add an option to turn the effect off and essentially revert back to the old behavior. Initially I thought we would even use the old water sprites, but because we had to change the tile transition definitions, the old water would look really bad. I have decided to always render water using the new effect, but if you disable the animation, it will render frozen in time and will be cached to the offscreen buffer.

Since we were keeping the offscreen buffer logic around, we could utilize it for everyone if possible. I added a flag to cached per-chunk tile draw orders, that determines if the chunk contains a dynamic effect (and therefore needs to be rerendered each frame - if the animation is enabled) or if it can reuse pixels from the previous frame. This means when rendering chunks without any water (E.G, the middle of your factory), the new water effect will have no impact on performance.

Modding
When seeing this you might get excited about the possibilities for modding. Well, don’t just yet. The system has been setup for making it possible to define different tile effects, but at the moment it is limited to allow just 1, which is used to define the water effect. I plan to lift this restriction in the near future, but in the end you’ll be limited to only changing the properties of the effect we made. But that still might be interesting enough, due to ability to change the ‘noise texture’.

There is still no plan to support custom shader definitions before 1.0.

As always, let us know what you think on our forum.