Factorio News

Read this post on our website.


Up until I looked at the source code, I was always confused about the differences between "Start campaign", "New game" and "Scenarios". New game seems like the same thing as "Scenarios"->"Freeplay", but are there any differences? We then later added a few more bonus scenarios, but they are hidden in the scenarios menu, with no explanation about what each is, what to expect or if it works in multiplayer. I believe it's very important to communicate to new players information about the game's content. It's also important to show that freeplay is the intended way to play. So all this prompted me to rework the main menu a bit.

I started with the structure. The structure always seemed odd to me, compared to what I'm used to from other games. Important options like "Load game" are lost among options that are never used (like "Replay game").
So I came up with a new structure. It looks like this:

• Continue
• Single player
  • New game
  • Load game
• Multiplayer
  • Host new game
  • Host saved game
  • Browse public games
  • Browse LAN games
  • Connect to address
• Map Editor
  • New scenario
  • Convert save
• Settings
  • ...
• Mods
• About

The first new thing to notice is the "Continue" button. Since "start the game and continue my last save" is probably the most common thing players will do, it makes sense that there is an option for this right at the top of the main menu. The button will contain the name of your latest save. Pressing it will immediately load the game and get you in game. Due to implementation complications, for now it only handles save games and it will NOT connect you to the last server you played on if your last play session was multiplayer, but I might implement that if it's highly requested.

Next, everything was grouped into either Single player or Multiplayer. There are much fewer options, since "Replay game" was moved as a small button in "Load Game", and every way to start playing the game was moved to the new "New Game" GUI.

The "New game" GUI shows all the ways to play the game. It also groups them nicely, places freeplay on top, shows a description and even a nice image. This GUI is used for new game, multiplayer hosting and map editor, thus simplifying the menu quite a bit.



For modders, scenarios can now contain a description.json file. In the file "order" determines the sorting in the New Game GUI; "multiplayer-compatible" determines whether the scenario is shown when trying to host multiplayer games. "multiplayer-compatible" was added to description.json file of campaigns also.


While working on the main menu, another thing I changed quite a bit is how logging in is handled. With Sanqui's help, we did some small improvements, such as better error handling and error localization, but a more important feature is being able to log in using Steam only. I found it annoying that even though you bought the game on Steam, if you want to play online, you need to make yet another account, whose email and password you are probably going to forget.

For the Steam version of the game, when you try to use any online feature, the game will try to authenticate using Steam.

• If you have an account and that account is linked to your Steam account, you will be automatically logged in without having to remember your password.
• If you don't have an account, the game will ask you to choose a username (your nickname in multiplayer games) and then log you in. No password or email or email confirmation required. We call these "mini-accounts"

"Mini-accounts" can be upgraded to normal accounts by going on the website, logging in using Steam, and then adding an email and password. They can be used for the non-steam version of the game.

These changes are ready to be released, so you should see them as soon as we release 0.18, soon™.


A few years back, we were using a collection of hard drives stuffed into a leftover workstation as an office shared drive. This drive had all sorts of stuff on it, from unfinished art assets, to a collection of pictures of developers in a wind tunnel, we had it all. The inevitable day came, and we ran out of space on the disks. A decision was made at the time, to buy some new, high density drives, and put them in a QNAP enclosure. This is basically a little computer, with 4 front mounted hard drive bays, and some special software for file shares and management. We figured this should be less hassle since it’s designed to be used by normal people. This was supposed to make our lives easier, as it should be an easy-to-use setup for normal people. It even had a friendly GUI with a little clippy guy!

"It looks like you're trying to setup replicated live snapshots"

[h3]Shenanigan #1[/h3]
After only three months, unfortunately the little guy died. Doesn’t power on, just dead. Of course, we start the return process, but it’s going to take about a month to get the replacement sorted, during which time we will be without access to our files. So, we did what any reasonable capitalists would do, and we bought our way out of the problem once again, by just buying another QNAP NAS to use while we waited. When the warranty replacement arrived, we would use it as a backup target.

Side note: we couldn’t actually read our data off the drives we took out of the broken QNAP. The QNAP OS is just Linux with a custom GUI on top, so you’d expect we could get our files by plugging them into another Linux machine, but no! QNAP have customised their Linux kernel in a way that makes it impossible to read on a normal install (for those interested, they modified LVM to add some more efficient form of snapshotting, from what I can tell). Mmm... delicious vendor lock-in!

[h3]Shenanagain![/h3]
All was well with the world of large file storage in Wube software, until one day disaster struck again!
After a solid 14 months this time, the replacement NAS that we had bought also died. At this point, we begin to question our decisions.

[h3]ZFS to the rescue[/h3]
With our original setup, we had a normal PC running the ZFS filesystem. We have decided to just return to this approach. The final lesson is, that sometimes the "buy the solution" easier option is not actually easier at all. Sometimes it’s just best to invest the time and effort to do it right yourself. If you're a technically inclined person who's not afraid of a command line, you should really check out ZFS. Despite some recent misinformed statements by highly influential figures, it is a really great filesystem with advanced features not really available in any other production quality filesystems, like snapshotting, checksumming, and live replication.
Oh, and you should probably avoid QNAP NASes...

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

Read this post on our website.


Our e-shop is now open again after taking a break over the holidays and new year.

We have also restocked our new Factorio sew-on patches, so if you didn't manage to pick one up over the last weeks, now is your chance to order one.



[h2]Learnings from the Introduction/NPE[/h2]
After deciding to cancel the Introduction/NPE (Tutorial/Demo) we took some time to assess what we learnt. Here are just a few of the points that we took away from the experience:

• Players dislike being told that they must restart.
• Players (ironically) don't have regrets after they restart.
• It is valuable for new players (< 30 hours) to rebuild 1-3 times.
• Lowering player constraints increases design difficulty.
• People like Compilatron to be there.
• People don't like it when Compilatron does anything for them.

In addition to those, self-motivated discovery of new mechanics (FFF-327) is a more important part of Factorio than actually using the new mechanics. This means letting the player do things the hard way, and not rushing them to the realization that there is a better way. For example, veteran players know not to handcraft science packs for 30 minutes while standing still, but forcing a player to discover this by artificially not allowing them to handcraft, lessens the Factorio experience.

[h2]The Campaign Conundrum[/h2]
While we were working on the Introduction/NPE we were also researching and designing what we wanted from a full featured Campaign. The game already had a Campaign which took the player up until Advanced circuits, but there was a feeling that we could do better. For the last year we have been working on and off to implement the design we came up with (from here on called the Expanding campaign), as talked about in FFF-245, FFF-257, FFF-291. More specifically the design was trying to remove the feeling of lost progression that comes from starting a new level and being forced to build a new factory from scratch.

After the Introduction/NPE was cancelled, we took the holiday period to reassess if this goal was worth pursuing, and thought we should at least prototype some alternate solutions before committing completely to "the one design". The prototype came together very quickly this week because we were able to reuse a lot of work from the Expanding campaign prototype.

Now we have two prototypes and wanted to present the ideas behind them:

[h2]1. The Expanding Campaign[/h2]


This is the main prototype that we have been working on so far. A single map which starts small but grows after each objective is complete. This would emulate Freeplay gameplay in that the player can build very large bases and expand in the directions they want, but with quest objectives to steer the player towards building the rocket.

Technology and progression are preserved perfectly, since we never ask the player to start again. As a result, the player can build a really big factory. This prototype focuses more on the long term problem solving that Freeplay requires, such as deciding where your next outpost will be.

Main Problem: At the end of each 'chapter' the number of different situations the player could have gotten themselves into is near infinite. This makes it very difficult to predict the state the player is in, and construct an appropriate challenge. Clever objective and map design should be able to mitigate this issue.

[h2]2. The Separate level Campaign[/h2]


Consisting of approximately five separate missions, each with an interesting starting condition. At the start of the level, all the technologies available in the last mission are pre-researched, and the player is given a new subset of the remaining technologies to be researched.

Every level the player needs to build a new factory. They will have some starting items, and the gameplay is about short term problem solving. This would be very different from Freeplay and similar to what people expect from traditional campaign content. If the player fails, or wants to try a different strategy, they can restart the level and not lose a lot of progress.

Main Problem: Players need to rebuild their factory each level, repeating things they have already done. This is especially problematic in a game like Factorio. We imagine that this issue can be mitigated by making the starting conditions interesting.
[h2]Conclusion[/h2]
While these two prototypes have some large differences, there are many aspects they share:

• Freeplay will stay the same regardless of the choice here.
• No story.
• No exploration gameplay.
• Same tech tree as Freeplay.
• All content of Freeplay available at some point.
• Complex concepts (oil/logistics/trains) are broken down into smaller pieces.
• Almost identical quest structure.

These two approaches are actually very similar in their core quests, this is more of a decision on how we present the progression. Internally we are still discussing which approach is more appropriate for Factorio.


Over the last weekend the Youtuber The Spiffing Brit hosted a server with the goal of completing a speedrun with 500 players online at the same time. There were 2 streams in total, one on Friday evening, and another on Sunday. Things went a lot more smoothly on Sunday, and we managed to reach a peak player count of 462.

Spiff has edited down the stream from Sunday into a much shorter video, so those who could not attend can enjoy the spectacle.

[previewyoutube][/previewyoutube]

There will be some further attempts to set a new record soon, with some upgraded hardware. Just recently one of the organizers of the server on Sunday has confirmed the order of a i9-9900k with 10 gigabit networking. If you are interested in more info on the servers, you can join the discord here.

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

Read this post on our website.

Hello,
The office here in Prague is still 'closed' until next week, so not much is happening (so our team can rightfully rest). Things will get cracking again on Monday, and our first task is to get 0.18 done!

For that reason, the FFF today is a little on the short side.

2019 was quite a 'typical' year for us. We released 0.17 early in the year, did some bug-fixing for about 6 months, and then we went back to development work. Saying that, we hit some major milestones this year:

• There was the all time concurrent player peak of over 22,500 with the 0.17 launch.
• The historically low count of bug reports on the forum.
• 2 million sales which we reached just last week.

You can see some correlations between this timeline and the commit frequency graph below.

Please note, the number of commits does not reflect the value and quality of an individual :).

It seems like we are somewhat 'in-sync' with each other, which I suppose has good and bad effects.

This year was also pretty good for the FFF blog itself. I would even say, this was the best year yet, with the highest quality and most well received posts we have ever produced.

In terms of readership (on our website), here are the top 5 FFF posts of this year:

• Friday Facts #283 - Prepare to Launch
• Friday Facts #282 - 0.17 in sight
• Friday Facts #317 - New pathfinding algorithm
• Friday Facts #303 - Under 100 bugs (but still not stable)
• Friday Facts #278 - The new quickbar

No surprise that our 0.17 launch announcement ones are the most popular.

And here is a graph showing the total website viewership statistics, because I also find them super interesting. You can really see the spikes every Friday :D. It is also funny, this year we started getting a lot of spam emails asking about posting 'sponsored articles' on our website. We would never accept any such proposals.



We really have a tough journey ahead of us this year, we are getting ready for the game to come out on September the 25th... Do or die, come what may. There are 9 months remaining now, and we have our work cut out. We'll keep you up to date on our progress, and we hope you will keep us up to date on your thoughts, at the usual place.

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.