As stated in previous FFF's we will be making some changes to the demo and tutorial content in the game. I wanted to clarify exactly what is being removed and what it is being replaced with, as this content is almost ready for release. If you would like to catch up on the topic, you can read Kovarex's piece in FFF-327, but I will also summarize it here. Right now the NPE/Introduction is the scenario that is used as the demo (0.17) and as the tutorial in the full game (0.17 stable, 0.18 experimental). If anyone has played the tutorial in the last 12 months, this is probably what you have played. The First steps campaign was a series of three levels which used to make up the demo and tutorial in 0.16 and earlier. They were introduced in 2014. We have been working on revamping these levels to bring them up to 0.18 standards. Very soon the NPE/Introduction will be removed and the First Steps campaign will be reinstated, both as the full game tutorial and the demo.

Merch store open again Klonan 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.

Map editor Lua snippets wheybags In the last few weeks, we've really accelerated our work on the campaign. We've been pushing ahead a lot with both the scripting and blocking out the physical level design. One of the problems we've come up against a lot, is that we often need to perform custom edits to the map, which are quite tedious, but not common enough to add a new tool to the map editor for them. For example, something like "disable all the spawners in this region". This kind of problem is easily solved with a little bit of custom Lua code, but getting the specification of the area we want to edit into Lua is a painful process of noting down and typing out location coordinates. It is also easy to lose track of these Lua snippets, as there is no good place to save them. To solve this problem, we decided to add a Lua snippet tool to the map editor. This tool will let you drag your cursor over an area, and it will then run your custom Lua code on that area. The snippets are named, and saved in your player-data.json, so you can keep them around for later. For example, this simple snippet replaces trees with biters. Currently, there doesn't seem to be a very big scene for community made custom maps/scenarios with custom maps, and we're hoping that the example from the campaign once released, as well as the much improved editor we have in 0.17 will encourage more people to give this a go.

Warning this Friday facts is about the Introduction scenario, not about anything that will be in Freeplay Factorio. You may want to read previous FFFs (FFF-257, FFF-284) about the Introduction. TLDR: the Stable candidate of the Introduction scenario is now in Experimental please play it and send me your screenshots. Feedback especially on the “freeform endgame” would be greatly appreciated. We have also released a Experimental version of the Demo, be sure to send this link to your friends ASAP. SPOILER WARNING: If you have not yet played the Introduction Scenario, go play it before you read this.

Demo upgrade for stable Abregado TLDR; We have released a new version of the Introduction campaign to the Experimental branch. If you are following the campaign development please play it again and send us your feedback.

New Campaign Abregado Have you ever been playing a Freeplay game and realised you don't know what your next big goal is? And then, once you decide to pick a new goal, you realise while you worked on automating the last goal, there were 10 new technologies unlocked and now you don't know which to pick next. These are the situations we hope to address with the new full Campaign. A guided Freeplay, in which the player plays through the whole tech tree, without being overloaded with choice, while still having the permanence and unidirectional progression of Factorio. The permanence problem has already been solved using the new map expansion technique which is playable in the Introduction scenario. Over the last year we have been working on the bigger design task of unravelling the tech tree and breaking it into a set of choices for the player. This task has been made all the more Interesting as the tech tree is also constantly getting tweaks and revisions over that time as well. I look forward to providing more insights but for now I will leave you with one example (read: spoiler): Just to note, we won't be changing the freeplay tech tree, which will still have all the choice and diverging paths as it does now.

The release (kovarex) So we finally released the 0.17 experimental this week. (patch notes) Hooray :) Fun fact: The release script failed to post the release announcement on Steam and Reddit and we were wondering why. The reason is that the patch notes were so big, that it exceeded the maximum post size (40k characters). If this isn't the indication that we should split our releases into smaller chunks, than nothing is :). Code wise, it is clearly the biggest release, and the amount of bugs we have to go through correlates with it. In other words, there are tons of bugs of all variety. We want to fix everything eventually, but it will take time, so we had to prioritize this week to aim for the most generally playable version before the first weekend after release. That means mainly unloadable saves, unavoidable crashes, game failing on startup, and the most frequently occurring problems. Our automatic bug reporting system is helping us a lot with the last one. It is uncommon, but sometimes the automatically uploaded crash report doesn't have enough information for us to be able to fix the bug right away, but the number of times we see a crash happening is still extremely useful for prioritizing. When we see a crash on the forum, we can cross reference it to our automatic reports, and if is one of our 'top-hits', we know to investigate it right away. The most prominent crash related to loading specific kind of save happened with pipe ghosts happened more than 200 times. It was fixed (obviously), but lets wait and see what our top hit of 0.17.4 will be after the weekend. Overall this means, that bugs that are not critical, require design discussions or are not that simple to fix are not being dealt with right now. Also, we got quite a surprising cake gift today. It is extremely delicious and we are extremely thankful for it :).

Factorio Nomenclature Abregado Today I want to discuss some common problems that we see in video games. Inconsistent Terminology When I asked out loud "So what is an Intermediate Product anyway?", I got a similar reaction as when someone mentions The Berlin Interpretation at a rougelike convention. So what is an Intermediate Product? Well it is a product that is used only as an ingredient for something else. No, that's not right because Science Packs are not used in any recipe. So what then, Intermediate products are just things that you can use Productivity Modules on? Perhaps they are simply items that can be found in the Intermediate Crafting menu. Then are they not Intermediate Recipes? To give another example, answer these questions: Name the action a player performs when they add an entity to the world? Name the action a player performs when they remove an entity from the world? Name the action a player performs when they add a ghost entity to the world? Name the action a robot performs when they add an entity to the world? Name the action a robot performs when they remove an entity from the world? Here are a few situations where the game displays your possible answers: A player builds. A player mines entities. Robots repair and build entities, but wait… the player places buildings and builds ghosts? But here Robots are constructing machines. Here the robots are deconstructing items! This leads into a discussion about what is an item and what are entities, and that discussion leads us into the next point... Internal nomenclature leaking out During game development it is very common to use internal names to refer to mechanics, items, or characters. It does not feel like such a big deal, and many early access games simply ignore the problem completely. I'm not going to point any fingers, but if you look you will find some examples. Oh wait, here is some from your favourite early access game! Internally, things that exist on a surface in the game are called entities. All these items are capsules internally, but only 5 of them are actually labelled as capsules. Really, these should be categorised by how players use them, and indeed there is an attempt to do so. Remotes are items used to trigger an effect, Grenades are things you throw... but why is the Poison Capsule not called a gas grenade? There are more inconsistencies but to keep this article reasonably not-short, I will let you find the others yourself (and to save something for a future FFF about Tooltips). Why change? You might be thinking that this is not a big problem. Some others might be thinking that the problem is too pervasive to bother changing. There are a few reasons why it is important, the first, and most important of which is our quality mindset; everyone on the team here wants the game to be as great as possible. Next we should see this increase the quality of the translations. A translation is only as good as its source, and having a consistent usage of words can go a long way to helping the translators do better work. The effect of this can be increased by providing a dictionary of important words to the translators so they can be sure to always use the same term in all places. Since we are also working on a guided experience (Campaign), this would also help us give much clearer instructions to the player. An example of confusion here would be if one quest said "Place a chest" and another said "Place the item in the chest". The player needs to read the entire quest caption (probably twice), and can never build up a mental map of our language. This leads to the player spending more mental energy (cognitive load) while playing the game. Changing this to "Build a chest" and being consistent, allows the player to create mental shortcuts, meaning the quest tasks require less effort to understand. Finally, consistency in terminology will help new players, and I don't just mean sub-1 hour playtime players. Factorio is a 'Big Game' and players are encountering new items, entities, concepts, and text for a long time. How many hours did you play before you discovered this helpful trick, or this one? How to change? We could make the vocabulary consistent with what the current player base uses. This option sounds pretty good until I started asking people questions similar to those I asked you at the beginning of the article. Here are another two as a refresher: Where do biters come from? I come in 7 colors, what am I? The only wrong answer is if you said there was only a single right answer. Prepare your rotten tomatoes, Ben is about to say something unpopular. The influx of players that are to be expected from 1.0 give us an interesting option. We could theoretically change the vocabulary of the game to be more consistent, reasonable, and generally more helpful to players. Then, as new players join the community, this new language will slowly replace the old. This would help ease communication between all players; veterans and new addicts alike. Consistency will also help polish the experience to the level that players expect from the game. Who should change it? Before Rseding jumps in with some awesome news, I would ask you to have your say in this Google form. It will be fun to see what you come up with, and I will publish the results in a few weeks.

In FFF-241 we discussed how the game delivers information to the player in a number of confused ways; Blinking arrows and circles, chat messages on the bottom left corner of the screen, objectives in the top left, orange modal boxes bubbles on top of the player, and so on. These problems are exacerbated on high resolution monitors, where the information becomes even further spread apart. We have tried a few ways to unify this information, but much of it was required to be in the world space, or needed to have a link between the screen space and the world space. The common solution to this is to have the GUI 'point' to an entity in the game world, but we wanted something more interesting.

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.