In the last FFF, we presented that we now have the capability to show real game simulations in the Tips and tricks. Naturally we asked ourselves what else could we use this new technology for...
We've dreamed about this multiple times in the past, but the technical roadblocks didn't make us think too seriously. We'd like the main menu background to be a real animated simulation of the game, similar to what Transport Tycoon or Rollercoaster Tycoon games have.
Instead of things like cinematic trailers, we always present the game in its true form, and the menu background does not follow this logic. Also, any time we improve any graphics, a static image immediately gets older while a real game simulation is updated automatically.
We've created a variety of scenes that each demonstrate some feature(s) of the game, from first miners all the way to the artillery and Spidertron. The screen is quite zoomed in and the factories are rather small, so it's more of a demonstration of the game's features rather than a showcase of "the best things anybody has ever built".
The scenes are randomly rotated, where all of them have to play once before any repeat.
The main menu should include both Factorio and Wube software logos.
The Factorio logo has been used in many places from prints to trailers many times already. Its concept is that the logo is an entity like any other, and integrates itself into the world by being built there if at all possible.
The Wube logo is different, both graphically and in concept, so we can't represent it as an entity. It makes a lot of sense that Wube is in a layer underneath the world of Factorio, so we're using it as a special water tile.
From now on, the Factorio entity and Wube water tile are both buildable in the map editor without the use of mods. The "water-wube" only works well in specific positions, as it repeats in a 8x8 tile pattern, so fitting it in an existing factory can be tricky.
To make it clear that behind the menu is not your factory, every scene has the logos in the exact same position, and the screen has a vignette-like shader on the edges.
The Spidertron was the last thing added to 1.0, people apparently use it a lot, which means we received a ton of great feedback, and the polish of the Spidertron will be generally worth it. Here are the biggest tweaks we made:
The Spidertron now moves its legs when being built, to make it almost always buildable.
Before: Static leg positions prevent placement
After: Legs move dynamically so placement is not blocked
Spidertron now moves its legs out of the way, so buildings can be constructed. This applies both for ghost building and manual building.
Before: blocking the construction
After: let me move out of the way!
The decision to make legs not collide with the train makes sense, as you can't control the leg positions so precisely and they are also invulnerable. But it looks kind of bad when there is a spider leg in the middle of the rail and the train just goes through it, so we made the spider legs unable to step on rails.
Before: Spider standing on the rails
After: Spider avoiding the rails
The change required us to use one more collision layer for the base game, as rails needed to have their own layer. This would leave even less spare collision layers for the modders. Since Rseding found some unused bytes in the entity data, which is basically free real estate, we could increase the collision mask bit-size from 16 to 56 without increasing the data footprint.
What this means for modders, is that there are now open collision layers from `layer-12` all the way to `layer-55`, and mod conflicts will be much less likely. To help somewhat with managing all the new collision layers, Klonan wrote a small Lua util lib called `collision-mask-util`, which provides a bunch of helper functions. It is hoped that if mods use the functions provided in the helper lib, it can allow all mods work together without hardcoding specific special cases. If you have any suggestions for functionality of this helper lib or have any questions, please let us know.
We fixed not only that spider item colors didn't show in the inventory, but we also fixed the way items are rendered on the ground and belts. This includes spider remotes, blueprints, upgrade planners and such.
Before: The items on the belt use the item prototype icon
After: The items on the belt render the item data and details
One of the main uses for spidertron is to let them build using the personal roboports, but the lack of an automated resupply method made the process less flawless than intended. This applies also to using them for combat, as restocking ammunition, repair packs and such, had to be done manually.
Spidertron now supports copy-paste, which not only copies the color, name, and logistic requests, but even the equipment grid contents, which it takes from the player doing the operation if possible. This removes the tedium of setting up additonal Spidertrons.
Ok, so we have Spidertron working well, it can semi-automatically request stuff and build in remote places, but it just amplifies a different problem we have had in the game for quite some time, and it is the awkwardness of ghost building.
The ghost building is a great example of a feature that was technically complete, but I was personally avoiding it as much as I could, because it was missing all the quality of life improvements available with the manual building.
The most frequent thing I'm missing is the fast replace, especially with belts, to either upgrade them, or just change the direction. So this was logically the first thing to solve.
To make things not easy for us, the ghost building must be able to fast replace not just ghosts, but also entities that are already built, which basically applies for all these features that will follow. This doubles (or more) the amount of combinations that have to considered internally, but I believe the result is worth it.
Adding the feature for just this one case opens the floodgates for all the other QoL improvements, as once you get used to one, you expect them all to be there.
This means, that all the Belt ⇆ Underground belt, Belt ⇆ Splitter, Pipe ⇆ Underground pipe fast replace logic and more, so we just did it all.
Another basic problem with ghosts was, that power pole ghosts didn't show wire connections. It did work for circuit connections, as these just had to be preserved, so the groundwork for this was already done. This means that it wasn't really that hard to implement, not only to show ghosts connections, but also to show connections inside a blueprint.
Once ghost poles started to show the connections, we could completely remove the logic of revived poles trying to connect to new poles, as instead, it followed the pre-determined connections from the ghost state, so the process is more deterministic from the user point of view.
Here comes the nice cherry on top. Once we have this logic in place, making blueprints preserve the wire connections could be implemented almost for free, so the game now supports it, and problems like this could finally go away after years and years of repeated suggestions to make this happen.
Over the years, the most prominent argument against this being implemented would be, that how would it manage connection of the bluperint to entities already existing in the world. Well the solution we missed is so obvious. The connections inside the blueprint are strictly following the original, while the connections to the entities already existing on the map are being automatically created as before. So you should be able to use blueprints as before even if you don't care about the connections.
Build by dragging is just another example of something that had to work for ghosts as well, so it now works for all the currently supported entities: poles, undergound belts, and underground pipes.
Apart from ghosts, there is one tweak to building by dragging for poles. The previous logic seemed to be fine:
This logic almost does what we mean when we say build by dragging, but what we really mean in our minds is to build a connection to the last pole as far as possible regardless of other poles in the vicinity, so things like this don't happen.
So we fixed that.
This was an example of a final tweak to do in FFF-360, so it was basically mandatory, and it serves its job fine. Now you can continue right into joining a MP game, hosting a game, etc. However it is related to another bigger subject, and it is the Cancel versus Continue struggle.
The main motivation to start on this topic was this dialog:
It happened to us countless times that we just set up the item, the value, and press E... Oops. I need to do it again, and confirm it this time instead.
The general rule is, that when users use your UI in a wrong way again and again and again, you can either really try to teach them to use it "properly", or you can just make this usage correct. Internally, the key "E" and the key "Escape" were doing the same thing, but in our minds, not really.
Typically the user sets up something in the game window and when they are done, they close it with E. This connects E with confirmation of what is done rather than cancellation. This realisation leads quite straightforwardly to the change we made in the game, which is actually stupid simple (a good sign):
Once this was made to work in all the relevant windows, it felt very natural to start using it in many different places, and the game feels more fluid. We even added a special sound for clicking the Green buttons and confirming them with 'E', so it all clicks into place.
We hope you have enjoyed reading about some of the upcoming changes for 1.1. If you have any thoughts or feedback, you can let us know at the usual places.
