Read this post on our website.

WoW classic has been released, which means several of our top men have taken time off to spend hours raiding and having fun in Azeroth.

This isn't great timing, as a few new bugs related to train signals appeared. We want to get these bugs solved before we do another release (another stable candidate). As it turns out, the only person with the skillset to fix these specific train signal bugs is also deep into levelling his Priest...

We are still making the rest of the preparations for the stable release. We have started writing up the stable annoucement blog post, and have produced a 0.17 postcard image. Other than the few more critical rail bugs, there doesn't look like there is much else to block the stable release, on the forum we are down to 27 bugs.

Since there are so few bugs left to deal with, some of the team has starting working on 'post-stable' features. Wheybags is working on the new campaign, Oxyd is diving into some detailed pathfinder improvements, and Rseding has started work on some particle optimizations. We will delve deeper into these topics and more in future FFFs, as we always love to do.

Heat pipes were released with 0.15, since then, we (the GFX department) contracted a debt with this feature. The original plan was to be able to visualize the amount of heat by using a glow on the pipes. Due to the tight schedule of the 0.15 release we decided to postpone the feature.
Finally Ernestas took care of it, and we can proudly present it integrated in the game.



As you can see, the pipes emit light due to the red hot metal. The fact that they are connected to the reactor and the heat exchanger, made us make some extra patches. It would look wrong if the heat pipes were glowing, but the pipes on the reactor were not. The final result apart from beautiful is also very readable for the player, which is the main point of the entire design.



The glow intensity is proportional to the heat. Now the visualisation should be crystal clear. The new graphics are already merged into master, so will be included with the next experimental release.

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

Read this post on our website.

The boring phase of bug-fixing is still going, slowly but surely. Stable should be released next week, but with some people on vacation (Ben, Jitka, kovarex, Klonan, Sanqui) and with the release of WoW Classic, it might get slowed down a bit. (By the way, some of us will be playing on Pyrewood Village, Alliance, so if you want to have the chance of meeting Twinsen, kovarex or dominik while leveling, you can join that server).

So since there's not much happening, this week we decided to explore some unpopular or controversial opinions about the game from within the team.

In Wube we don't have a very strict management structure, everyone is free to have ideas and opinions about almost all aspects of the game. This means that with almost every change we argue and discuss a lot before making a final decision. Sometimes we argue about everything, from the smallest GUI change, to how a major feature should work. This is probably not a bad thing since this means changes are usually well thought out and unpopular ideas or changes don't make it to the game very often. Some people feel quite strongly about their opinions or sometimes the team is very divided on what should we do. Today we'll share some of those opinions and controversies.

Keep in mind that these are simply opinions and none of them will actually make it into the game, we are simply sharing them to have an interesting discussion.

What I always liked about Factorio is that it's a very precise game. Ratios, throughputs, crafting times are all well explained and even if it gets complicated, everything can be calculated to the last item. Miners mine resources at a precise rate, smelters and assemblers craft items at a precise speed, belts move the items at a precise throughput. But inserters... due to their behavior where they track items on the belt before grabbing them, they don't have a precise throughput. This really grinds my Iron gear wheels, as it's hard to even know if an inserter will be fast enough to load a simple assembler. There are Wiki Tables and References, but they are ridiculously complex since it depends on the inserter type, source, destination, belt type, belt orientation and inserter capacity bonus. Even after accounting for all that, the numbers are still not precise since it depends on timings and how items are placed on the belt.

My proposition is to remove this complex movement of item chasing and have inserters move to their predefined pickup location and immediately pick up the closest item (in the case of a belt).This will:

• Make inserters have a constant throughput. It will still depend on some factors like stack size (e.g. stack inserter will pick up faster from chest than from belt), but it should simplify things significantly and allow us to have a calculated throughput for chests and belts that we can show in inserter tooltips.
• Prevent all the issues with inserters getting stuck (e.g. burner inserters running out of fuel because they chase items they can not grab). We often argue if this is a bug or not and if it should be fixed.
• Improve performance (maybe significantly). Inserters currently chase items throughout it's entire swing, tracking the items on the belt each tick and searching for a new item each time one goes outside the belt (which happens quite often for blue belts). Removing this requirement would mean less memory access to other entities and much simpler mathematical calculations. Since inserters are the second most common built entity, these improvements could lead to a big UPS boost.

But on the other hand, this will mean:

• It will graphically look much worse. While I believe we can do many things to make this look good enough (by separating drawing animation logic from game logic), it will probably not look as nice as it does now.
• It will remove some of the nice organic feel of the game. And it will remove some (arguably) fun emergent situations.

Combine this with the fact that changing something so core to Factorio in such a significant way would have big implications. So we decided this wont be done.

The blueprint library has always been a controversial topic. We argued about how it should work technically, in multiplayer or if it should exist at all. But one thing that I particularly don't like is blueprint import/export. It's obvious that it's more fun to make your own setups and it's probably universally agreed within the team that importing large sections of factories is not what players should do. This promotes "instant gratification", it eliminates the satisfaction you feel after finishing your creation you spent hours tinkering and planning. And could easily make a 100-hour game into an 10-hour game. It's sad when we release an update and the first comment is "does anyone have the blueprint string for the nuclear reactors" or someone immediately asks for an artillery shell production blueprint.

It's our job as developers to incentivise the player to play the game properly. If importing blueprints is obviously so bad, why are we providing this tool as a vanilla tool? Not only that but we also place it in the "tools" section, as a shortcut in the main screen, as if you are expected to use it often.

So my proposition is that this tool should only be modded in. By making it a mod it's clearly not a an intended way to play.The very common counter argument is "since it's obviously not fun, players won't use it. Put it in and let the players decide". That's like putting a "level up" button in an RPG and saying "well it's obviously not fun, it skips content, players won't use it, but let them decide". Yes they will, as soon as they encounter a problem a player will evaluate his options. A tempting "skip-ahead" button is irresistible in such situations.

It's hard to remove such a powerful tool now, since it's oh-so-tempting to import that nice blueprint book with belt balancers, so you don't have to deal with designing those complex things yourself. Until a different consensus is reached, the tool will stay in game. But I urge players to restrain themselves from adding too many blueprints to their library that are not their own (or their friend's).


Weapon lock on and the distinction between shooting with spacebar and C is a constant source of confusion for new players. Also, it is just weird and not even fun. Weapons should all work like the shotgun, you point and shoot, and the bullets hit whatever is in that direction. There's only one button to shoot, and that can be spacebar. We could take inspiration from the huge number of top down shooters out there to figure out satisfying weapon mechanics that would work with this new style. Even if you don't like this style, we already have it for some weapons (shotgun), and using it for some weapons but not all is inconsistent and confusing. (Klonan made a mod a while ago which does something like this).

Currently, you can get by with only walling off part of your base, responding to attacks as they come, and leaving the rest fairly open. This runs opposite to what "most new players" [citation needed] would expect. For example, I always started off by walling and turreting my entire base, presuming that if the biters noticed a part of my perimeter that was uncovered, they would just go through there. The counter-argument is that it makes the game less fun, because you spend way too long building massive defensive walls instead of making your factory. My counter to that is that for a lot of people, making defenses is very fun, everyone loves turtling in RTS games. Maybe it's just my play style, but this is what I was doing anyway even when it's not necessary, and leaving big holes in my walls just feel wrong. IMO if you don't enjoy that, you should just turn off biters. Also related is the way that biters will sometimes ignore your structures, if they are not polluting or military. For the same reasons, I think you should have to defend your railway lines, power poles, etc.

Related to the point above, I think that clearing the bases inside your pollution cloud should provide only a very temporary respite from attacks. Biters should very regularly expand back into your pollution cloud, meaning you always have to defend. Alternatively, the whole pollution cloud mechanic could be removed, and replaced with a worldwide pollution count.

Every other interaction between a belt and a building uses an inserter to move the items to/from the belt. Why are miners any different? From a pure consistency point of view, I think this should be removed. As far as I know, the reason it has been left this way so far is just convenience. (Bonus fact: I used to put inserters in front of my miners for an unspecified-but-way-too-long time when I was new to the game).

During our in-house testing, one of the things we did was invite people who had never played the game before into the office to try the new introduction campaign, while we observed them. One stumbling block that almost every person hit, was connecting their steam engine to the water output of their boiler, instead of the steam output. I understand that the current setup allows for some interesting layouts, but IMO it is not worth the usability cost.

Pipes and fluid have been a constant annoyance for a long time. Thanks to the labours of another of our developers (Dominik), this has improved greatly, and is due to improve even more. However, if I had the choice, I would just remove the headaches outright, by making pipes function like magic liquid teleporters. Each "pipe network" (a block of connected pipes) would have a set of inputs and outputs. The load would be drawn equally from all inputs, and distributed equally to all outputs. Of course, this would mean that there would be no flow limits for pipes. So you could, for example, have a massive array of offshore pumps connected via a single pipe to a large nuclear plant, and it would work just fine. There would also be no way to visualise the flow, so the windows would have to be removed. IMO, the cost is worth the gain.

I can't get my wife to play Factorio with me because she's not really that into Factory building.But she and I have been playing Satisfactory because it gives herreasons to explore the map and discover new places and collect items.

The obvious change that could be made to Factorioto accomodate that play style would be to scatter useful itemsaround the map.I imagine things like an abandoned railyardthat would give one early access to a few prebuilt enginesand rails, totally changing the way an early factory is designed.

But there is a second aspect leads to Factorio not being very exploration-driven,and that is that you can see ridiculously far and nothing obstructs your line of sight.Who needs to explore when you can just plop down a few radar towers?Forests would be much more meaningful if you couldn't see through them,and had to actually poke around and through them to know what was there.(I personally take inspiration from Ultima 3for line-of-sight calculations in 2D games).

And speaking of line-of-sight-blocking terrain features, we also need mountains.Not just rows of cliffs, but large and impassiblemountain ranges that compliment the impassible (but non-sight-blocking and land-fillable)bodies of water.

Games with a first-person perspective automatically give you the line-of-sight effect.Another thing that true 3D game engines give you out of the box that 2D onesusually don't is the possibility of non-planar worlds.Bridges and tunnels can provide alternate (or secret) routes and interesting loops.But it is possible to get some of the same effects out of a 2D engine.Since Factorio already supports multiple surfaces, it wouldn't be too much of a stretchto add a cave system (preferrably with an odd topology) underneath the surface surface,with entrances in mountain sides.

I'm not sure that making vanilla Factorio more fun for peoplewho want to focus more on exploration is itself controversial,but all these features take time and energy to build and maintain,and "Factorio isn't supposed to be about exploration",so it hasn't been a priority.

In my estimation, the main cause of bots becomingoverpowered in late-stage factoriesis that they take up zero space(large amounts of logistic or construction bots can occupy a single point on the map)and take zero time to pick up or drop items or to deconstruct things.This leads to the following:

• Laser-turret-creeping enemy bases is trivial because construction bots can instantaneously place enough turrets to completely overwhelm all the biters.
• There is no reason to mess with belts at all when bots can 'teleport' unlimited resources between storage chests.

Buildings taking time to construct (such as they do in games like Total Annihilation)would to some degree solve the first problem,since an already dug-in force would have a chanceto defend itself while turrets are being built.

Bots taking up space (so that they have to queue up to pick up and drop off items)would solve the problem of bots completely obsoleting belts;to transport large numbers of items quickly you wouldneed to spread out the pickup and load boxesto give the many robots space to work.

The main reason we're not doing this is that bot movement logicis currently written such that calculations are needed only when something changes(a robot completes its task, its target is moved, etc).Having to keep bots separated would add a lot more calculationsthat need to be done while a bot is en route,which would probably result in a lot of complaintsfrom people with huge bot-based factoriesthat the game got all slow.

Similar to the overpowerdness-of-bots problem,being able to carry multiple locomotives (or rocket silos)around in a backpack or in a train car feels silly.Big things should require time and space to move around.

Solving that would require completely changing how construction works—large things would have to be built on-site a la Total Annihilation or Satisfactoryinstead of being preassembled.But that could lead to its own interesting situations.Some objects would require more resources than can fit in a standard stack,so special assembly buildings would be needed.

There are mods(such as Rocket Silo Construction)that try to do this with certain buildings already.

I believe it is alright for a game to have power-user controls that are not bound to any keys by default. For example "Toggle exoskeleton" introduced with a 0.17's toolbar is a feature that most people probably will never need, and lot of people won't even realize it exists. It is probably useful for some people, and it also useful that it can be toggled by a hotkey, but it doesn't need to be bound to any keys by default. People just get confused why they run slow when they press the hotkey by accident, even if they knew about the feature, but don't actively consider its existence.

I think if we changed our attitude towards default keybindings we could go nuts with adding new shortcuts and there would be little bit for everyone. I mean, how many people use hotkeys for connecting or disconnecting trains, and how many people would use a shortcut for toggling manual driving in trains.

In Factorio the game makes a large effort to not punish the player for experimenting: you can mine up anything you build and move it somewhere else or just try different setups. The game doesn't punish the player for this (or so most people think). You can hand craft things and if you change your mind just stop crafting to get the ingredients back.

When it comes to furnaces and assembling machines this is different. Anything which is in-progress when you mine a furnace or assembling machine is lost. If you had a Kovarex enrichment process running with 40 Uranium 235 and you mine the centrifuge the game deletes all 40 of the Uranium 235 and you're left with nothing.

In a previous version of the game it would just give back everything it had consumed when the recipe started. However, because of a possible incredibly tiny exploit related to productivity modules and being able to get an extra % of items back if you time it correctly this was removed (bug report).

We continue to get bug reports about deleted items and all of them get filed under "not a bug". There have even been mods created to address this specific shortcoming in the game.

Remember that since we are focusing on 1.0, these ideas are currently nothing more than a cause for heated discussions in our office. But let us know what you think (on our forum) and maybe we will change our mind based on the feedback. (maybe after 1.0...)

Read this post on our website.

Hello,
we had a party last night in the office to celebrate the work we have done over the last 6 months on 0.17 stablisation. It was nice to have most of the team together to share some beers and pizza.

Unfortunately a couple of nasty bugs appeared this week, in no small part due to forum member boskid and his crusade to find bugs. In the last month alone boskid has reported over 20 bugs, so very special thanks are due. Saying that, we have been efficient in our fixing, and are now down to 32 open bug reports on the forum.

While there are issues being reported, the number of crashes is at an all time low. Below is a comparison between 0.16 and 0.17.



We compared the current number of 0.17 crashes to the number of crashes in 0.16 before we released 0.17. From what we can tell, comparing the number of crashes against average player counts, about two thirds of players are playing on 0.17. Factoring the player counts into the data, we can determine that 0.17 is close to being as stable as 0.16.

A lot of the crashes are from older 0.17 experimental releases, which might be skewing the data. Additionally about 1 in 20 of the bug reports are due to Cheat Engine, and not something we can fix.

What this means for the stable release, the plan is the same as last week. We have just release 0.17.66 with a bunch of fixes, and if it weathers the weekend player base and nothing critical arises, we will mark it as stable next week.

Forum member lilstrip has spent over 8 months working on a map, based on the idea of an Abandoned Colony/City, first talking about his baby in this thread. After long last he has a version ready for publishing, and a little bit of a backstory to go with it.


Click to view full size

In the years before the gates shut Nauvis used to be a promising colony. Equipped with a massive orbital ring the planet was an absolute power house when it came to building ships for the Tyrador Safeguard Coalition.

Sadly the colony was lost in the first AI war long after the collapse. In reality things weren't going too well in the first place after the gates closed, famine and unrest were a common occurrence for the colony of Nauvis. To this day [REDACTED] of the AI war still roam the system in massive numbers and eventually a few decades later the location of the colony was lost..

Xterminator has made a video showcasing the map too, if you want a more hands-on preview.

https://youtu.be/kBlFp9FF81k

You can find the download link and the information on the scenario in the forum post. The scenario itself requires a pretty beefy PC to run, a map this large is stretching the limits of the engine a little.

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

• Blocked underground pipe connections (see e.g. https://forums.factorio.com/73840) are always highlighted.

• Fixed crash when using the close button while the client is saving the map for desync report. more
  
• Fixed a crash related to settings copy/paste of some modded assemblers. more
  
• Correctly highlighting blocked connections of modded underground pipes. more
  
• Fixed a case of disappearing fluid in a special fluid furnace configuration. more
  
• Fixed programmable speaker caused crash when using --disable-audio command line option. more
  
• Fixed that an underground pipe ghost did not split fluid systems. more
  
• Fixed that an underground pipe ghost did not split blocked connection. more
  
• Fixed that fluids in assembling machines and furnaces would get voided any time mods changed. more
  
• Prevented construction of underground pipe that could crash the game due to blocked pipe connection. more

• Added LuaEntityPrototype::terrain_friction_modifier read.

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

• Modded achievements and their progress are now stored even when the mods adding extra achievements are temporarily removed. Up to 5000 modded achievements are stored indefinitely. more
  
• Programmable Speaker sounds now change volume accordingly as player moves. more
  
• Rocket Silo sounds now change volume accordingly as player moves.

• Fixed tightspot level 5 expecting old chemical science recipe. more
  
• Fixed Transport belt madness inserter exploit. more
  
• Fixed that filling energy of entities in map editor didn't work for accumulators in electric network.
  
• Fixed a crash or desync that could happen after assigning a build_base command to a single unit. more
  
• Fixed that mining drill covering more than 1 infinite resource showed the mining speed as sum instead of average. more
  
• Fixed that infinite item based resources with yield of more then 100% didn't actually mine more. So yield of 260% for example means that it mines 2 resources and 60% probability of 1 extra.
  
• Fixed cloning of accumulators in the map editor not setting available energy correctly.
  
• Fixed a desync related to cloning accumulators. more
  
• Fixed 2 crashes related to custom-switch. more
  
• Fixed that train could consider itself being parked in station when in fact being misaligned. more
  
• Fixed that activating deconstruction planner/blueprint/blueprint tool from the shortcut by pressing the buttons didn't clear the cursor if it wasn't empty. more
  
• Fixed condition operator button visibility when dragging conditions in the train schedule GUI. more
  
• Fixed few layouting issues with scroll panes.
  
• Fixed that biters could get stuck in narrow passages between water tiles. more
  
• Fixed that members of unit groups could sometimes get far ahead of the group. more

• Added CraftingMachinePrototype::match_animation_speed_to_activity.
  
• Added LoaderPrototype::structure.back_patch and front_patch.

• Added ability to clear a sprite or sprite-button by writing nil or empty string to LuaGuiElement::sprite. more

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

• Range modifier and shooting speed modifier are now shown in ammo tooltip and ammo turret tooltip.
  
• Allow pressing ESC to cancel saving or downloading the map while desynced. more
  
• Added copy paste from assemblers to infinity chests, similar to requester chests.
  

• Fixed crash when loading a save containing modded crafting machines with fluid boxes, with mods disabled. more
  
• Fixed turret range drawing not accounting for ammo range modifier in world and in map view. Fixed turret unfolding and animation not accounting for ammo range modifier. more
  
• Fixed case of swapping left and right lane of underground belts. more
  
• Fixed desync related to marking and then un-marking combinators for deconstruction. more
  
• Fixed Infinity Chest GUI showing wrong label when modded as a storage chest. more
  
• Fixed when target of combat robot changed force to an allied force, the combat robot wouldn't stop attacking it. more
  
• Fixed silo script error using generic on_event function. more
  
• Fixed a desync related to using multiple custom fluid indexes in a recipe. more
  
• Fixed some labels getting cut of in the statistics GUI, on some translations. more
  
• Fixed a crash that could sometimes happen when fighting large groups of biters. more
  
• Fixed a special corner case of signal internal state consistency. more
  
• Fixed that the circuit and logistic network buttons in the train stop GUI were swapped. more
  

• Combinators can now be activated or deactivated through LuaEntity::active.
  
• Added LuaEntity::upgrade_target read.
  
• Removed the ability to convert a table address into a string.
  

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

Read this post on our website.

Hello,
We had a lovely surprise waiting us this Monday, one of our fans had sent us a delicious cake:



It didn't last very long...



Thank you very much Conn! It certainly helped with the bug fixing push this week.

This last week we have made a big push to fix as many remaining bugs as we can, and we are down to only 36 reports on the forum. Since these remaining bugs aren't really hard crashes, save corruptions, or desyncs, we are looking to consider 0.17.64 (releasing today) as our 'Stable candidate'.

What this means is that, if all goes well over the weekend and nothing too serious comes up, we will mark it as the 0.17 stable next week. We will continue to fix bugs and issues after the stable, and we will also start our work on the features of the 'next stable', so the GUI improvements and all the rest we have mentioned in the past.

In the next few weeks a lot of the team is going to be on vacation, so things won't get up and running with the new feature work for a while. This experimental period has been quite a long one, we had a lot of new things to fix and debug, and a lot of technical debt from the year of development. There won't be another release quite so large, we only have a few major things left to cross off the list before we can call Factorio finished:

• All new GUI's implemented.
• New Campaign and mini-tutorials.
• Completed high-res graphics.
• Maybe some small surprises along the way.

By no means are any of these easy, but each day brings us closer to concluding this chapter of Factorio history.

Just in time for the stable version, the prototype documentation for mods has received a major overhaul. The backend has been converted to use semantic mediawiki to store the prototype documentation data in a machine readable format.

Using the new ability to query the stored data, prototype pages now display all their base classes at the top for easy navigation. Furthermore, each prototype page now provides a compact overview of not only its own properties and their types, but also the properties it inherits from other prototypes. The documentation also boasts a new overview page that lists all 199 prototypes and their 1943 fields.

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

• Inventory filters tooltip now shows they are inventory filters to avoid confusion. more
  
• The quickbar tooltip now shows what shortcut to use in order to clear it.
  
• Quickbar filters can now be set from the ghost cursor.
  
• In Introduction, changed some places Compilatron stands at to be less in the way. (https://forums.factorio.com/74138, https://forums.factorio.com/74018)
  

• Fixed some combination of graphics options could cause infinite loop at 95% of sprite loading in the demo. more
  
• Fixed assigning empty table to sprite definition would not cause loading error but crash in-game instead. more
  
• Fixed a desync related to accumulators in multiple networks. more
  
• Fixed transitions on tiles where landfill, grass and water meet. more
  
• Fixed logistic network technology description did not mention buffer chests. more
  
• Fixed "use-version-filter-in-browse-games-gui" config option didn't work. more
  
• Fixed possible crash in introduction scenario if player builds turrets too far to either side. (https://forums.factorio.com/74133, https://forums.factorio.com/74060)
  
• Fixed electric coverage visualization was not shown when hovering mouse over invisible widgets. more
  
• Fixed a crash when using a path_resolution_modifier of 8. more
  
• Fixed introduction leftover invisible entity after cutscene. more
  
• Fixed introduction bug where sometimes Compilatron wouldn't build things properly. more
  
• Fixed "toggle filter" control setting would not work if bound to modifier key and left or right click. more
  
• Fixed introduction bug where poles could still connect to the generator after it was destroyed. more
  
• Fixed introduction possible crash when removing power consumers. more
  
• Fixed missing laser-beam entity from demo. more
  
• Fixed issue with walls in hidden smelter section in introduction. more
  
• Fixed that biters could form too many attack groups when aggroed by artillery. more
  
• Fixed that clicking and dragging electric poles in multiplayer latency didn't work correctly.
  
• Fixed that fast-replacing assembling machines with fixed recipes didn't work correctly. more
  
• Fixed a crash when deleting surfaces during the same tick as auto-save running. more
  
• Moved integration patches of crash site entities to decals render layer. more
  
• Fixed that inserters would pick up from the left lane of a loader even when positioned closer to the right side.
  

• Added LuaEntity::request_from_buffers read/write.
  

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

Read this post on our website.

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.

The tutorial components of the Introduction are working very well now. There is still more polish to do, but I feel confident it is ready for new players of all kinds.

The rest of this article will discuss the Introduction, but from the point of view of a player who has not payed for the game yet. Once 0.17 Stable comes out, the Free Demo will be replaced with just the Introduction Scenario.
The old demo has a very limited amount of content, and only about 2 hours of playtime. The content it does present is very dated, and hardly could be called representative of contemporary Freeplay Factorio, it did not even include Research!

We had some design constraints for the new demo, some of which were:

• The player can fail during the demo
• Difficulty is respectful, Fake danger is disrespectful

Whatever happened, we hoped that the new demo would demonstrate a wider range of Factorios concepts, including a small taste of deathworld difficulty. I would say we were too successful.

We decided to do this with a final quest where the player has to quickly complete a long research while the biter attacks increase in strength. The player needs to be completely attentive, otherwise their defense will fall over.



An invisible, dynamic difficulty curve meant that everyone was challenged to the breaking point, veterans and new players alike. See FFF-284. For the goal of being a challenge, I would say it was working well.
People loved it or hated it. I received many elated emails saying how intense the final battle was and how sweet the victory felt. I also received pseudo-hatemail about 1,000 hour players rage quitting.

The reason a lot of vets were failing was because they were pretending to be new players. This generally meant playing as a vet (using shortcut keys, and high APM, heavy pollution) but placing few turrets, generally in sub-optimal locations, and being lazy with ammunition delivery.

Newer players felt pressured and were generally able to pull off a close victory. Many said they were overrun at the end, but still were victorious, giving an interesting moment to leave the game and start freeplay with a high heartrate.

Feedback was far more positive than negative, but from the negative feedback there were two recurring themes.

• The most common negative feedback was that such intense combat is not representative of Factorio.
• The second most common feedback was that the player did not expect such a difficulty in a 'tutorial' level.

This removes the chance that the player can lose, but introduces new problems with the design. It removes ammunition as a production pressure, and makes Turret placement irrelevant.
This sounds like it could work and for the second problem listed above, it does. The player has more time to react. However this means that only new players experience the challenge, as they most likely have built the fewest Labs, and take the longest to finish the quest. Vets will finish before the attacks built up to any meaningful level. Just making it easier for the players who are able to overcome the challenge the most seems odd.

In order to have a decent number of biters so the production challenge is not lost, the waves need to be very large. For the player to have enough notice between waves, there is a chance they will be able to finish the research before the first one comes. Also the most common failure state was when a Turret with 200 rounds is destroyed, meaning the player cannot craft enough new ammo to keep up with the waves. This happens more often with bigger, less frequent waves.

All three of these solutions have one thing in common: we would need to implement them in a way that removed the challenge almost completely. So I suggested an alternative solution.

Now there is no timed research and defence quest at the end of the Introduction. Instead the player is told to destroy Biter spawners to reduce the attack frequency, and then they are left to deal with Freeplay style attacks. The structure of the final quest is similar to Freeplay itself "Research a technology at the bottom of the tech tree". The player now needs to automate Logistic Science packs to win the Introduction.



If the player cannot survive here, they will not survive a Freeplay game, but realistically the biter challenge in Default settings Freeplay is not particularly worrisome.

Having a great Demo is important to us. We don’t want someone to pay for the game, just to see if they like it. It is also fits well with our no sales policy. We already offer an extended refund period to players who buy on our website, if they gave the game a red-hot go but discovered it was not for them.

Demos are in general a super cool thing from the 90’s that most people here wish still existed.

So we will increase the amount of content in the demo. You can continue playing at the end of the Introduction, and I suspect there is about 10 hours of stuff to do. We are also adding more recipes and technologies to the Demo.

The new list of what is available:



A complete and unique demo techtree that uses Automation and Logistics science packs, Mining Productivity infinite tech, Shooting speed infinite tech, Grenades, Steel, Piercing rounds, Car, Medium power poles, Heavy armor, Submachine gun, Assembling machine 2, Turrets, Lamps, Long handed inserters, Gates, Walls, and more to discover.



The size of the final play area is also much larger.


Click to view full size

We have released the changes today, and also released an experimental version of the demo. Please let us know if you have any feedback or suggestions in the usual places.

• Combat robotics 2 technology now require Laser. more
  

• Fixed fluid mixing checks for some setups when setting an assembler recipe. more
  
• Fixed flying notifications showing player's inventory updates were visible to all forces. more
  
• Fixed error during PNG decompression would cause crash on Linux. more
  
• Fixed that save files could become very large. more
  
• Fixed that cloning furnaces wouldn't preserve the crafting progress. more
  
• Fixed inserters being slower and rotationally asymmetrical after the previous version.
  
• Fixed that wandering units could be activated for longer than necessary. more
  
• Fixed a crash when trying to check if 'game' is equal to anything using the Lua API. more
  
• Added a check for overlapping crafter fluidboxes to detect wrong mod configuration. more
  
• Fixed desync related to inserter ghosts and belts. more
  
• Fixed setting health of item stack of item-with-entity-data to 1 would do nothing. more
  
• Fixed a desync with the map editor resource editor. more
  
• Fixed a desync with the map editor decorative editor. more
  
• Prevented some rare cases of fluid mixing tied to underground connections. more
  
• Fixed placing entities that consume type of energy other than electric would still show electric coverage visualization. more
  

• Added InserterPrototype::draw_inserter_arrow.
  

• Added LuaGuiElement::choose-elem-button elem_types "decorative", "item-group", "achievement", "equipment", and "technology".
  

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