Hello, a large part of the team is attending GDS , if you are in Prague and interested in Games, you are welcome to come as well.

Taming the random generatorTwinsen One of the things in the large TODO list for 0.17 is giving a final polish to the map generator. There are quite a few obvious problems now in 0.16, and some less obvious ones. Here are some of the fixes and improvements (some work in progress): All combinations of settings should no longer create strange maps such as circles of cliffs. Much more predictable starting area resources that don't overlap each-other and are not covered by water. The resource generation settings now have a much more dramatic effect (previously they had little to no effect). Increased the number of steps (small, medium, big, etc) for each setting from 5 to 9 for even more customization. The starting area will always contain water, most often a lake close to the spawn position. Since the algorithm for generating ores was pretty much completely rewritten, there are many small improvements. Now for the less obvious problem: unpredictability. I saw quite a few people complain with vague comments like "the map generator sucks". So I often asked them what the problem is in detail. Some were complaining about the above problems, some did not understand what the settings do, and some had problems finding a "good map". I saw quite a few players click "regenerate" like crazy until they got a map with fat patches in the starting area, big oil patch and also uranium, complaining that it's too hard to find a "good map". Due to the randomness we seem to have set the expectation for "good map" a bit too high. Oil and uranium were never intended to be in the starting area, but due to the randomness of the generator they sometimes were there. Also sometimes maps were so wild that you would start off either swimming in resources or desperately looking for another iron patch. It would be simple to just say "that's just RNG, deal with it", but blaming poor game experience on RNG is just bad design. So what we did is: The starting area contains only iron, copper, coal and stone, in very predictable amounts. Uranium and oil are explicitly excluded from the starting area. Starting area resources are usually in one ore patch each (depending on settings). The starting area patches are usually close together. The starting area size setting no longer affects resource placement, it just has a fixed size. Outside the starting area, the regular algorithm "kicks in" so you can still get quite wild results, but they are far enough that it averages out. I believe this is a good balance where you can still have different experiences depending on your luck, but your starting experience is much more predictable and does not leave you with the feeling that you got screwed over by the map generator. We definitely don't want the map generator to be extremely flat and predictable. Opinions on the subject are quite wild too, with people having different expectations of what a good map should look like, so we try to only make changes based on actual problems. This might seem a bit controversial so we can add an option that disables this whole starting area logic, for purists. We plan some small tweaks coming to biters also (a tiny bit more biters close to the starting area), small tweaks to terrain, cliffs, water generation and possibly some new features to make the generated trees and decoratives look better. Most of these problems including the obvious and apparently simple ones were not that easy to solve. It's hard to make random generators do what you want, so TOGoS will explain what it took to actually get it done.

Mod portal features (Klonan) Sanqui has been quite effective these last weeks getting stuck in with the mod portal, so we have some interesting additions to talk about. Mod deprecation A modder can mark a mod as deprecated, which indicates they are no longer updating or maintaining it. The typical case is a mod will add something relevant for the current version of the game (E.G, a mod to scan the players starting area), and then an update to the base game makes the mod obsolete. Just deleting the mod could potentially cause problems for people playing an older version, people might ask what has happened to it etc. Marking as deprecated will keep the mod up on the portal, but it will be hidden from any public searches. This way people downloading using 'Sync mods with save' feature can keep playing, while new players won't stumble upon a mod that is no longer useful or up to date. It also preserves the downloads and discussions in case the author wants to revive it later. Collaborators It is often the case, that a mod author will want someone else to help them maintain and manage their mod, for instance if they are going on holiday when a major release is coming out. The way it has worked in the past, another modder would have to come and upload an updated version of the mod under their own name. Now a modder can set another player as a 'collaborator', which means they can help out will all the maintenance of the mod. Collaborators can do everything the author can do, except add or remove collaborators. You might also spot the other feature, transferring mod ownership. This lets the author give the mod completely to a collaborator, in the case that they are no longer interested in working on the mod at all. Discussions notice Mod authors can now display a notice above their mod page discussions, informing the users of any useful information. For example, an author might prefer you to report bugs on their GitHub page, so the notice will inform users of where they should go. An additional option allows the author to disable the discussions completely, in the case they have their own forum/thread somewhere for discussions. If you have any ideas for an improvement to the mod portal, please let us know on our Mod portal discussion subforum.

Status report (Twinsen) On Monday June 18th, we marked the last version of 0.16 as stable. There were no major problems, so now we are almost exclusively working on 0.17. Work on 0.17 is progressing well: Regarding the new campaign, we are already internally playing a rough version of the new player experience. We are still trying to figure out the exact and final style and concepts for the improved GUI, but we have some GUI windows implemented in game already, plus many base widgets. We use those to get a feel of what works and what doesn't. The new graphics back-end rewrite is nearing finalization. A closed-beta branch was sent to a few players to test that rendering works correctly across different hardware. The rendering is faster and no major issues were reported so far. But there is still much to do, such as improvements to VRAM usage and many experiments with shaders. Since from the graphics department Albert is working on the GUI and V453000 is working on the new campaign, only Ernestas is left working exclusively on the entity graphics. He is reworking some more entities for high-resolution, so expect some teasers in the future. There are of course other small projects that are ongoing, such as improved pipe-fluid physics and improved map generation, but more on those when they are fleshed out. Oh, and our coding always goes as planned without any problems.

Ok→Cancel versus Cancel→Ok (kovarex) A really strange debate started as a continuation of FFF-238. I insisted that the button order should obviously always be OK Cancel, as in any UI I see around. But little I knew, that this is actually specific to windows, and on Linux or macOS, the order is reversed: Eventually, we figured out, that we are not the first one trying to solve the problem. The solution we are now experimenting it sounds like a bad idea: "Make it so much different and Factorio specific, that the way it is done in your specific system will not interfere with your muscle memory". Which brings me to the load game dialog mockup:

New player experience (V453000 & Abregado) 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?

AMD Ryzen crashes (Klonan) The long fight with the elusive Ryzen bug (more and more) seems to finally have some resolution. A few weeks ago I sent an email to AMD, filling them in on the details of the crash, and asked them if they could help us solve this. Very quickly I was put in touch with a member of their CPU engineering team, and they got to work with their investigation. After a few days, and after providing them all the information we have (log files, source code, crash dumps etc.), the cause of the issue was identified. Some other developers in the industry also had this problem and worked with AMD to fix it, so it's unlikely that the CPU bug was fixed only because of us, but we are honoured to have contributed to this. Unfortunately we do not have any technical or deep insight into where exactly the problem lay, or what the fix was, as it was somewhere between the motherboard BIOS and the Ryzen chipset drivers. So if you are running Factorio on a Ryzen system, we advise you to update your BIOS using the files and procedures found on your motherboard manufacturer's website, and update your chipset drivers to the latest version.

Hello, it has been extremely cold these last weeks. It's one of those weeks when we can't think of anything to write about. So we will try to write some small parts.

Belt compression (kovarex) The decision of how to approach the belt compression in 0.16 was not an easy one, we were basically facing two possibilities: Splitters are the only way to reliably compress a belt. Compression is automatic everywhere (inserters, sideloading, mining drills). Non-automatic belt compression is kind of an nice example of emergent gameplay mechanic that I liked. It was not forced on players, but it allowed to get some extra efficiency if they cared enough. On other hand, the solution to the problem is kind of obvious, and having to use it in all the setups everywhere might add more repetitiveness than fun. So after some discussions, we decided to make compression automatic. But we weren't really sure how to do it. The problem is, that once the items are pseudo-randomly added to the belt, with lot of gaps not big enough for another items to fit, it is not clear how should the additional inserters compress it: The solution was, that whenever there is any gap bigger than the standard distance between items on a belt, item can be inserted there and for a (usually) brief moment, the items are squashed together closer than usual. But once the belt starts moving, the gap between the two squashed item extends to the standard size. This change required us to do some fundamental changes to the belt logic, which could introduce a lot of new problems, but since we just wanted this to be resolved in 0.16, we had to do it now. The result is, that the same setup in 0.16.25+ results in perfectly compressed belt: The belt mechanics are now easier to use, but the game also flows more nicely. The belt flow still needs to be controlled and belt balancers are still needed. As that feels to be the more interesting part of belt handling to me, I am happy with the final result.

Taipei Game Show 2018 (Twinsen) After a long 14 hour flight back, Albert, kovarex and I arrived back from Taipei, after our attendance at the Taipei Game Show. Jitka started her vacation by staying there to visit the Taiwan island. We stayed there for 7 days (2 days in the business area, 3 days in the convention area and 2 days of free time where we visited the city). In the business area we met many potential business partners and got way too many business cards. We made some friends among the other indie developers and tried all kinds of fun, weird, interesting and some bad indie games. The convention area was very crowded, with 350,000 visitors slowly trying to make their way through the fairly small convention hall. I can't speak for the others, but I still enjoyed myself. Even though it was crowded, most of the games were in Chinese, and I only got to try one AAA game, there is something about being surrounded by games, gamers, and game developers that makes me feel great. Our booth was in the indie area. We had many people coming to try the game but also many fans wanting to speak with us and congratulate us for making a great game. AndrewIRL who lived there for a few years, invited us for dinner to "the best restaurant in the city", and we were not disappointed. Factorio is not an easy game to demo, since it takes at least 30 minutes to kind of understand what the game is about. But having the trailers looping on the screen, and having subtitles for the gameplay trailer meant that the people got a fair idea about what the game is about and how complex it is. While not the best, we had people start by playing the campaign. Most of them were leaving after the first level but some of them were also getting addicted and playing for multiple hours. We gave free Steam keys to some of the people who were more engaged with the game. It was a learning experience to see people play the game for the first time and to see the most common problems with the campaign, the interaction, the UI and the Traditional Chinese translation. The days were super exhausting though, many of us collapsing at the accommodation and sleeping for 10 hours. Luckily we had 2 more days to relax and enjoy the city before flying back. We mostly split up and each of us visited what they were most interested in, with me going through the electronics markets and riding a rented bike through the rainy streets. To give credit where credit is due, I'd like to thank the game show for inviting us and sponsoring our booths, and Razer for conveniently lending us the laptops we used to demo the game. Financially there is no point in us going to a game show, our attendance did not bring us any extra sales in Asia, as expected. The point of going there, for us, is to visit the show floor, play and see random games, make gamer friends, meet fellow developers, meet big fans of the game and maybe make some business partners. Since many of you mentioned PAX and some of us are interested in going there, we are trying to see if we can attend PAX East this year (April 5-8th). So you might have another opportunity to come and take selfies with some of the Factorio devs. From left to right: Jitka, Albert, Twinsen, kovarex.