Hello, version 0.15.30 was released today, and we consider it to be our first 0.15 stable version candidate, as long as no other big bugs appear, we will have 0.15 stable in a week. As the teasing never ends, it is time to show some ongoing work on 0.16 already.

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.

Hello, another week of tepid weather here, but the work on the final necessities to 0.15.0 continues with full force. More playtesting We started a new map on Monday, we wanted to see how the game feels with our new 'marathon' map preset, which (among other things) makes many recipes more expensive. What may seem like blasphemy to some, the expensive setting also changes a few of the normal recipe ratios, so new designs had to be thought up: Automated testing 2 A long time ago we talked about our automated testing in FFF-62, and over the last 2 years and 4 major versions, we've added quite significantly to our suite of tests. We have our server constantly running all these tests 24/7, and when something breaks it sends out a sternly worded email to the developers who made the latest commits to the repository. Its sometimes surprising how some innocent change can break some wholly unrelated tests, but it certainly helps us catch these issues before they make it out the door. This might be quite a short Friday facts, but we are trying to spend as much time getting things ready for release. If you have any thoughts or feedback, please let us know on our forum

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.

Hello, Today we have quite a range of new features and improvements coming in 2.0.

Hello, GUI improvements often surprise us with just how impactful they can be, even for simple cases, they can really compound on the quality of life.

Hello, we have written a lot about multiplayer in the past weeks, it started by the reports at the beginning of the rewrite, and now it finishes with our reports of mega games being played. But as most of our time still goes to bug hunting to achieve 0.14 stable as soon as possible, I just can't help myself:

Tile transition collisions Klonan We first mentioned a change to our tile transition logic back in FFF-199, and not long after in FFF-214. These two posts focused more on the visual side, and how it makes the game terrain look so much better. In short, the tile transition logic overlays an additional sprite over adjacent tiles, so that where the two tiles meet has a much more natural look. Left: Tile transitions on; Right: Tile transitions off. So while the looks were taken care of, we also had to deal with the 'feel' of the tiles. The easiest example of this is the 1x1 landfill 'stepping stones'. It really looks like you should be able to walk/drive across the 1 tile of water. So we added in an additional layer of collision checks, which will consider the transitions when performing the logic of what can go where. Now some of the cheesier among you will know that biters don't know how to get across these 1 tile gaps. That is because simply we never enabled the biters to use this collision check logic. One reason is that more checks means more UPS usage for the biter pathfinding, another is that we didn't think it was necessary. However it was available in the engine, and any mod could enable it if they want. That is exactly what I did with my Mining drones mod. Initially this seemed to work, and I thought it might make them walk around lakes a bit more naturally (like the player character does). However quickly I noticed that people were reporting on the forum that the game was crashing with the mod installed. I quickly reverted the change to my mod and we started looking into it. It turns out that the new abstract pathfinder we added for better unit pathfinding (FFF-317) was not set up to consider units using this tile transition collision logic. This same crash was happening sometimes without any mods installed, but the case was more difficult to reproduce, so this is a nice situation where mods help us work on issues in the base game. Recently I have been working on another unit heavy mod, Transport drones, and the principle design behind the mod heavily relies on the tile collision logic (the units don't even collide with entities). It turned out to be a really nice test of our new pathfinder, but also highlighted some of the issues that not considering the tile transitions can bring. By not considering the tile transitions, the drone takes an awkward path along the diagonal road. This week Oxyd finished his work on an upgrade to the pathfinder, so we can enable the tile transition collision logic with units. The change is immediately noticeable with the above example. By considering the tile transitions, the drones path much more naturally. With the logic now in place, we are debating whether to enable it for biters or not. We probably won't, it is only a minor change and would have a non-zero performance impact (a rough test puts the worst case at about 5%), but then again it is a fun way to surprise those who thought the 1 tile of water would stop the biters attacking, and it kinda makes sense they can walk over it just as the player can. Well we will see if there are any issues with it in the modded cases before any further consideration. As a bonus fact (this is Factorio facts after all), I spent a bit of time benchmarking some late game Transport drone based factories (screenshot), and found a few nice performance gains.

This week's Friday Facts is brought to you by Robert, also known as that guy from Romania. I'll be talking a bit about the feature I've been working on: the Combinators. The post is very fresh: Albert worked overnight to bring you the awesome combinator graphics and I integrated them in the game just minutes ago.

The many lessons learned from testing the new tutorial We have already pointed out, that we are trying to make a new campaign (FFF-245), and part of it is the core beginning, the NPE/tutorial. The tutorial is one of the very critical parts of the game, as if the first 15 minutes of a game feels shitty, there is big chance that the player will not play any further. I had this experience in many games myself. So the challenge could be articulated like this: "The current tutorial is okay, but can we make it great?" The approach in the current tutorial is to feed the player with the basic knowledge of how to control the basics of the game (the first mission and the start of the second mission) in the fastest way possible. The player is even given descriptive info like this, to diminish the chance of not understanding how the basic entities work. After few steps in the 2nd level, the player can start exploring his first self-feeding loop (make iron to make more iron). The tools used to this is mainly: The message dialog that stops the game and explains the player various things. Minimization of the amount of things the player can interact with to absolute minimum, so he can't start doing other things before the basics are clear. The possible drawbacks: The constant interruptions can get really annoying (typically around 22 message dialogs before the player starts to play relatively freely in the 2nd level). The possibility, that the player will mindlessly follow the step-by step tasks without understanding it, so he can become really lost later on, and the tutorial basically wouldn't help him to understand things. So the question is: Can we make a tutorial that makes these problems go away?, and alternatively, How big are these problems actually? The current direction of the new tutorial attempt is to never use the message dialogs, so the player can learn the game more fluently, and to leave way more things to explore, as learning things yourself has a better chance of success than force-feeding generally. We made a few tests of the new approach with a few people, the main takeaway, is that nothing is for free, and this approach created new drawbacks. If the player doesn't figure out something basic, it can be very frustrating for him to figure out what is going on when not moving forward for a long time. It might be possible, that some things are just not fun to learn by exploration, and it is more comfortable if they are force fed to you. I would compare this to a friend explaining you how to play a game for 5 minutes compared to 2 hours of trial and error. There are more possible outcomes from this, and we shall see how different tweaks of both strategies work in the testings. It might be interesting if you mentioned your experience with the tutorial in the comment section as well.