Being brought in to create content on a very mature project has been an interesting experience to say the least. One of the first things I did was analyse the features of the game and which kind of player the game currently supports. The obvious thing is that Factorio Freeplay strongly attracts and engages players who enjoy an open-ended sandbox type of game. Achievement statistics show that only about 11% of players on Steam have ever launched a rocket, which currently means 'won the game'.



What about the other player types? Well for those that are new to the game, or unsure if they are interested, we will have the New Player Experience. This is a free, combined tutorial and demonstrator mission which we discussed in FFF-241. But what about those that prefer a guided experience? This is the sort of player who wants to play the game, and experience all of what it has to offer, but wants to be taken on a journey. For these players we have the campaign.

Why do we need a new campaign at all? We find that the current campaign:

• Does not include all the Freeplay content as it currently ends after Advanced Circuits.
• Severely limits player investment by forcing a new factory to be built each mission.
• Does not convey the feeling of loneliness that the Freeplay does.
• Is showing its age visually, as it was made before high-res textures and the terrain rework.

To solve these issues we have set about designing new Campaign elements to act consistently to provide the player with a guided experience all the way from Science pack 1 to Space science packs.

The first step to achieving this is to have the map border expand each time the player completes a section of the main 'quest line'. This means that the player never loses any of their progress, and as long as these transitions are presented in a smooth way, the jarring effect of the old level restarts will be removed.



Having a continuously expanding map presents many other challenges, but we are confident that it will be worthwhile. This style of level will fit with the style of Factorio much better.

Such a map should also end up being as huge as a regular Freeplay environment so as to better place importance on exploration. Exploration in Freeplay is generally player motivated, such as when you are almost out of iron and need to find that next big patch. In a guided experience, letting the player know that there is something out there can give them impetus to dive into the unknown. This brings us to technologies.

Now that we have removed level transitions, we have also shot ourselves in the foot. How else will we deliver the technology tree in chunks? Simply making the entire tree available from the start of the game will cause all sorts of balance issues. In our NPE discussion we stated that new recipes should only be given to the player via research. In the campaign, unresearched technologies will only be given by moving to given locations on the map. These would include some non-generated terrain and pre-placed factory structures to help to player see where they are. These could also help to show concepts and workable designs, one thing that the current campaign does do well.

When designing the campaign, we look at many things in the game very closely and often we start seeing some problems.

One such problem that has been confusing players for a long time now is the fact that the most important ingredient for progression - the science packs - are unlocked in arbitrary technologies. On top of that we changed those technologies a couple times already, so remembering if that elusive blue bottle is unlocked by battery or advanced electronics just adds to the confusion.

So in 0.17 we are going to add science pack technologies which only unlock that new science pack, making it clear in the tech tree where you get them and what they will lead to. Doing this properly requires a bunch of changes to the prerequisites of many technologies, but those are generally just cosmetic changes that don’t actually have any bigger impact on the game.

Here you can see the technology tree for the Logistic system. The GUI rework is being worked on in parallel, so this will actually be much nicer to look at in 0.17.



When we were designing the High tech and Production science packs for 0.15, the purpose was to create a choice for the player whether after Science pack 3 they want to continue with a more 'production' or 'high tech' oriented method. Looking back, the idea is definitely good, but we want to make it more clear.

One of the big obstacles was that the Power armor mk2 required level 3 modules, which are a great candidate for production science pack - but Power armor mk2 is meant to be in high-tech. That made us only put the productivity module to the production science pack, but productivity modules without beacons and speed modules aren’t all that great, so you would still need the high tech science pack to make full use of productivity modules.

The resulting solution is that we changed the recipe of Power armor mk2 to require level 2 modules (which still require just Science pack 3) instead of level 3, and moved all of the level 3 modules to production science pack. Additionally the beacons are now unlocked with Production science packs without the need for High tech science packs. The total cost of Power armor mk2 is roughly unchanged, we just tweaked the numbers of modules it requires. These changes should already make both of the science packs offer quite appealing benefits, and it’s not so clear that one science pack is superior over the other.

Because of the new technologies for unlocking science packs, it is really easy to see what options each pack unlocks.





Overall we want to keep the campaign and the Freeplay technology trees exactly the same to avoid confusion, so any change we make, we make in both - which should give the Freeplay another layer of polish.

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

• Fixed wall related consistency check related to modded walls with altered collision boxes. more
  
• Fixed inconsistent train direction when reversing in a train vehicle that is not a locomotive. more
  
• Fixed that having more than 6 products didn't fit the ui, as it wasn't wrapped. more
  
• The system data path is removed from the log when it's automatically uploaded by the crash reporter.
  
• IP addresses are no longer hashed in the log file. All IP addresses are removed from the log when it's automatically uploaded by the crash reporter.
  
• Fixed crash when placing an entity with title while backers list was emptied.

You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.

• Another fix for setting PvP map dimensions to 0. more
  
• Fixed possible desync related to circuit networks.
  
• Another possible fix for multi-GPU setups on Linux. more
  
• Fixed that modded infinite inserter stack size research would wrap around instead of maxing out. more
  
• Fixed scenarios with partial identical names didn't work correctly. more
  
• Fixed splitter lane selection inconsistency when inserting into middle. (Now it is always right for both belts, splitters and underground belts.) more
  
• Fixed LuaPlayer::build_from_cursor. more
  
• Fixed a desync in replay that would happen if console commands were used during the play. more
  
• Fixed desync when setting inserter filters while it's connected to the circuit network more
  

You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.

Mobile users may see that the website is significantly easier to read today, that is all thanks to our new Python developer Sanqui. Apart from making out website more mobile friendly, we have a lot of tasks on the backlog that he will start working on soon.

His first major task is to speed up and optimize the matching server, with which he is already making some progress. A bigger rewrite for the long term is underway, but in the last week he has reduced a lot of the slowness and timeouts people were seeing during peak times. He will be taking over our database management and web administration from HanziQ, as well as spending time cleaning up our codebase, maintaining our web services, and developing features for the mod portal.

Plural localisations are needed here and there in Factorio. For example, when the time is specified, it can be either 1 minute 5 seconds, or 5 minutes and 1 second, so there needs to be some system to select the correct word depending on the count.

In 0.16, we have this very specific custom system of specifying some of the translations by 3 different forms, while very specific code selects the correct one depending on the corresponding number:

English:

The English translators might be quite surprised, why do we need 2 different translations for plural of minute? The Czech people reading will understand, as the Czech localisation file looks like this:

Yes, we (Czech people) have a different kind of plural for count 2,3,4, than the other plurals.

The problem is, that we eventually discovered that there are other languages than English and Czech (!) and plural possibilities in other languages are not as simple as English only speakers tend to think. For a reference, here is the sum up of the common plural forms.

This made it clear, that having different translation key for every possible form for every language would be too crazy, so we invented something more generic. In 0.17, the translation of X minutes (the number is now included in the translation to allow to put it on different position, or to add some other word somewhere) will look like this:

English:

Czech:

Romanian:
etc.

The rewrite of the rendering framework goes well. We are at the point where the game looks exactly the same (with minor fixes to line rendering) as our main 0.17 branch, and the only major thing that is missing is proper error handling - for example, we don't want the game to terminate if a screenshot command fails for whatever reason. I was surprised at how many things we had to rewrite, but we took our time, and I think it is already worth it. The game rendering performs significantly better (well, at least on CPU side of the pipeline for now - more on that in some future Friday Facts) in both OpenGL and DirectX.



Speaking of which, some people were wondering why do we even bother with DirectX, and not just to use OpenGL everywhere. The reason is Windows is still the main OS for PC gaming and for some reason, we can't squeeze as much performance from OpenGL as we can from DirectX (we are seeing about 30% more time spent in calls to OGL as opposed to D3D). It also seems the OpenGL driver quality is all over the place. We already ran into the problem where our first implementation of building sprite atlases worked great on Windows and macOS, but was so inefficient on Linux it took over half an hour for the game to load.

We are actually trying to design the new rendering around architecture of current-gen APIs - Vulkan/Metal/DirectX 12 - and in future we would like to create Vulkan and Metal backends, but we are focusing on older APIs first as a large portion of our current player-base doesn't have Vulkan capable hardware. By using OpenGL 3.3 Core and DirectX 11 feature level 10.0, we should cover 99% of our current players (according to our Steam hardware survey statistics). These APIs should be supported by any dedicated GPU manufactured in the past 10 years, and integrated Intel HD Graphics since Sandy Bridge. We'll still leave 1% of players behind, so they are going to be stuck with 0.16, similar to when we dropped 32-bit support, but everybody else should benefit from better performance and hopefully a better looking game eventually.

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

• Added technology price multiplier PvP scenario config.

• Underground belt marked for deconstruction no longer connects to other underground belts.

• Fixed some cases of fast replacement by underground belt. more
  
• Fixed corrupted config.ini in Steam cloud would prevent the game from starting.
  
• Fixed that using "Save and play" feature in the freeplay could specify the official freeplay map to be always that one forever. more
  
• Fixed underground belt connection overlay when hovering over another underground belt. more
  
• Fixed a crash when mods define empty result items. more
  
• Fixed a crash when switching games and joining quickly in the server browser.
  
• Fixed that clicking rail planner with no available path while recording replay invalidated all other actions of the replay. more
  
• Fixed a crash that would happen after opening a library blueprint that contained only entities from a disabled mod. more
  
• Fixed LuaEntityPrototype::braking_force return value. more
  
• Fixed LuaPlayer::ticks_to_respawn would read in seconds. more
  
• Fixed certain type of energy source migrations. more
  
• Fixed rare possibility of crash when two trains crash into each other. more
  
• Fixed a rare crash that occurs when train collides in a way, that its position is reserved back while approaching closed signal which caused path recalculation. more
  
• Fixed PvP error when setting map height to 0. more
  
• Fixed construction robot tutorial breaking when removing the radar from the storage chest. more
  
• Fixed crash when adding train station to a train while the train is modified (added/removed rolling stock). more
  
• Fixed that destroying part of a cliff with tile ghost under it destroyed the whole part of the cliff. more
  
• Fixed browse games dialog problems with the active game not being updated while searching. more

• Added support to set ReactorPrototype::neighbour_collision_increase which controls how much a reactor extends when connected to other reactors.

• Allow technology_price_multiplier to be less than 1 by script/scenario only.
  
• Added support for localised strings in LuaGameScript::write_file.

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.

The process of the GUI re-design is moving slowly but steadily. By making new mockups, re-thinking old mechanics, and with the proper feedback from a different range of people, the parts are falling into place.

I'm starting to feel very confident with the actual general contrast and font sizes. Also the conversion from high resolution to normal resolution is working just fine. These subjects are very important to move forward with.

Below you can see a demo of the current state of the new GUI. Not all the widgets are shown yet, but this document is helping us a lot in order to define the future elements.Seeing the big picture makes it much easier to tweak them altogether with a better coherence and consistency, not to mention for testing any kind of font, specifically non-latin characters sets, a subject that I personally have not paid too much attention to yet.

This document is being used also to create the general tileset and see how it behaves in the engine. This is a work in progress, and we are tweaking details constantly. Many things will change during the process. Overall here you can see a sneak peek of the Factorio GUI to come.

I want to also mention that we are actually taking care of the 8% of the population who has some sort of color vision problems. This subject is still very new for us, but we are without a doubt researching solutions to different conditions.



The moving to the new office went better than expected, and with the new carpet, it feels cozy.






We are currently using approximately 40% of the available space, so there is a room for growth if needed.

Let us know what you think on our forum.

• Fixed that consistency check failed on ghost wall entity on top of wall entity marked for deconstruction. more
  
• Fixed, that it was possible (through mod or script) to build ghost entity of belt/wall on top of existing belt/wall causing inconsistency later on. more

You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.

Hello,
this post is going to be more technical than usual, yet it might still be interesting to know the background of the process for some people.

0.16.36 is stable, but as we needed to fix some additional bugs, we started releasing experimental releases 0.16.37 up to 0.16.42 and so on. From the perspective of the player, there were a lot of new bugs introduced, unloadable saves, weird train problems, or even the infamous version 0.16.40 that disabled all signals causing trainocalypse which even made a baby cry.
Most of these problems (apart from the trainocalypse) were actually caused on purpose. It might sound weird, but it should make sense to you soon.

As far as I can tell, offensive programming is the best way to keep complicated codebase like Factorio relatively bug-free in the long run. The general idea is, that when we have some rule of something in the code being always true no matter what (this is called an invariant), we should never just ignore it if the rule is broken.

One of the invariants we had was, that there can never be wall on top of another wall. This can't be normally done, as the player can't just build wall over another wall, but with script, you can place entities even in a way that they would collide. But in the case of walls, you can't even build two walls on top of each other with a script. The reason for this is, that the walls connect to each other, and since there would be 2 walls at the same place, in multiplayer it could happen that the neighbour wall piece could connect to different walls for different players which eventually could (and it also did) cause desyncs. Similar invariants are set for belts, pipes and rails.

The second part of the problem occurred when the deconstruction planner and blueprints came into play, as we gradually changed the game in a way, that you should be able to mark any area of factory for deconstruction and plan a blueprint over it even before the area was cleaned. So suddenly, you can have a belt marked for deconstruction with another belt (in the form of a ghost) on top of it like this:



The third part of the problem was, that we decided that ghost belts and walls should connect with each other so it looks nice as explained in fff-211

To allow these 3 things to co-exist, we had to make several changes. The first thing to change was something you might have noticed: belts and walls get disconnected when marked for deconstruction.



The second thing was to allow walls (or belts) on top of each other as long as one is marked for deconstruction and other is a ghost. As things marked for deconstruction are not candidates for connection, the connection candidate is still well defined.

You can imagine, that making sure that the first invariant is still true might not be that trivial, for example:

• Make sure, that a ghost on top of an entity marked for deconstruction gets removed when the deconstruction is cancelled.
• Make sure, using teleport fails if the result would be in conflict with the invariant.
• Make sure, there are not other ways it could happen we are just not aware of.

The last point is the biggest problem, because if there is some other way the invariant can be broken, I want to know about it rather than have to investigate very complex desync reports. But how do I check that this never happens without affecting performance in normal games? For these kind of things, we have a method we call "consistency check". It goes through all the map and it checks different kind of integrity stuff in it.

The checks take quite some time to perform, so calling it on every save/load would affect the game too much, so we decided to call it only on version transition, which includes also transition of any version of any mod. The check can be also executed manually using a console command:


The question is, what to do when the check fails? To make sure that it will actually get reported, we decided that when the consistency check fails, the game instantly stops (crashes) and writes the cause and stack trace into the log. This forces the user (at least some of them) to give us a bug report, so we can try to figure out what is going on. After that we can just re-activate the migration that removes conflicting entities in a new version to make the save loadable again.

All the train bugs were also originating from the same problem. I figured out, that rail signals marked for deconstruction didn't disconnect from the rail, and could block building of blueprints with rail signals on top of them. This changed the invariant for the rail signal from always connected to rail if possible to be only connected when not marked for deconstruction.

Most of parts of the code were fixed properly, but there was one particular piece of code, that re-connected signal even when marked for deconstruction, which made the internal state inconsistent and the save not loadable until the migration to re-build rail segments was re-activated for the next version transition.

So now you know, why are there much more crashes when loading games and you hopefully hate me less, because now you know, that it was done in the sake of the long-term code correctness.

As always, let us know your thoughts and feedback on our forum.

• Changed the searching logic, that searching every word separately is only done when the fuzzy search option is on. more
  
• Fixed a desync when printing a Lua error to players with different installation paths. more
  
• Rail signal connection merge optimisation (tens of seconds instead of tens of minutes on big maps).
  
• Fixed that rail signal migration didn't update the state of the signal controlled by the circuit network. more
  
• Fixed decimals displaying in production statistics that caused the numbers to be too long. more
  
• Fixed high CPU usage on the main menu. more
  
• Fixed an issue when joining friends games through steam. more
  
• Fixed, that it was possible (with the use of script/mod) to build belt/wall entity (not ghost) on top of other belt entity marked for deconstruction, which could cause a consistency check fail later on.
  
• Added train path finding penalty for train with no path equal to 1000 tiles. more
  
• Fixed a crash when building modded rolling stock entities on diagonal rails. more
  
• Fixed "header errors" when extracting factorio zip files with 7zip.

• Added LuaEntityPrototype::collision_mask_collides_with_tiles_only and collision_mask_considers_tile_transitions read.

You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.

In the last several weeks/months we have been working on deciding the fate of the campaign and the demo/tutorial missions.

Hi, I'm Ben (Abregado). My experience as an educator using Factorio in the classroom means I have thoroughly examined new players (young and old), and have played the first 30 minutes of Factorio for as many hours as some players spend on a single megabase. The systems in Factorio are deep and interconnected, so creating an onboarding experience for a single concept poses many exciting challenges.

We find that the Freeplay portion of the game is already enjoyable to its target audience, but those who prefer a more guided experience only get a short campaign which doesn’t even utilize all of the features we’ve added to the game. On top of that brand new players need to dig through a tutorial which takes about 30-45 minutes to get to automation, which is what the game is about.

We want to keep the demo so that anybody who wants to try the game can do it for free, and get a proper representative introduction to what Factorio is. For Factorio, the demo should serve a dual purpose of a tutorial and a teaser, both of which we feel could be improved...

Currently we find the demo has the following problems:

• The impact of the first level isn’t very visually representative of what Factorio is.
• Gives the impression of being a Minecraft clone in the first tutorial mission by having to mine manually and do hand crafting.
• Key concepts like Assembling machines and electricity are not presented for the first two levels.
• Player actions are so heavily constrained that the player learns just how to solve the tutorial rather than learning the concepts we are trying to demonstrate.
• Each of the levels is disconnected from the previous. Which item recipes are available, that there are suddenly built structures and the location is completely different.
• Grindy tasks like obtaining X resources in 2nd tutorial mission don’t have any clear purpose. The player does it because they are being told to, not to achieve some other goal that would make sense in the progression.
• A lot of information is not important and just floods the player with noise, for example many of the
  messages.
• The places where the player gets information are scattered - Objective window in the top left, the player character talking to themselves in the console chat and the yellow "TAB bubbles".

The three different information channels competing for attention. In this case also two of them telling you the same self-explanatory information (where is the current objective shown, if you didn’t get it), while the chat informs you that your character is alive.



A typical objective without purpose. (I guess the game will tell me what is it for soon?)



Doesn’t this message resemble another game?
What we would like to achieve with the new design:

• Create an immediately gripping environment that better sets up the Factorio feel.
• Showing and teaching core concepts like Assembling machines and electricity in the first level using as little complexity as possible.
• Providing goals through the technology tree, working with laboratories and the technology GUI as soon as possible.
• Standardize the way players obtain new items. Every recipe has to be obtained through a technology - that way the player triggers recipe progression and gets them as a reward.
• Starting a new level should start the player at a similar progression state where the previous mission left off.
• Teaching by experimentation instead of jumping through arbitrary tasks. Letting the player coming up with their own solution of a puzzle.
• Unify the channels the player gets information from (mostly GUI improvements).

After finishing the demo, the player should be ready to continue by playing the main campaign, or jump straight to the Freeplay.

If you had to pick one entity that represents the game to you the most, which one would it be?

As you may know, some people who backed the game during the indiegogo or who decided to support the game by buying the "Mining Drill Operator" version of the game, they are able to have their name in game. These names are given to in-game Labs, Roboports, Radars and more importantly Train Stops. The backers are able to change their backer name from their account page. On every release we then update these names. While there is no longer any way to get your name in-game, we still support this feature.

Since these messages were not moderated, cheeky or offensive messages kept making their way in game. While having your trains station automatically named "Satan's Anal Railways" is mildly funny, it's a bit confusing and not very family friendly.

To avoid the need for moderation, we plan to disallow any further changes to your backer name in a week. So this is your final chance to get your final name in game. Keep in mind that at the end, we will go through the list and delete anything obscene or offensive, plus anything we find inappropriate, at our own discretion.
Hopefully we won't get a Dub the Dew incident.

As always, let us know your thoughts and feedback on our forum.