Hello,
we finished with the regular Friday Facts series, and yet, there is still so much we want to talk about. I want to clarify, that we are not going to release FFF every week, but there are a few of them coming in the near future.
The point of 1.1 isn't to add some new content, the main motivation is to finalise all the existing features so that they work together in a proper way. This may sound a little bit abstract and boring, but it will be explained more clearly in the upcoming FFFs. Believe me, the sentence "I didn't know I needed this until now" will come to your mind more than once.
The work on the 1.1 update started basically right after the 1.0 release, so there is already lots to show.
Right now we aren't going to make any promises as to when it is coming, but we will keep you updated on our progress with these blog posts, and give some notice before it is deployed. Though I'm quite certain that we are more than half-way through. To keep you happy until it is here, lets go through some of the changes.
This is a tiny story about Boskid's train related side project for a feature that was requested quite often (1, 2).
So imagine the situation: You're sitting in your factory and you need more iron... classic. So you build a nice railway to bring ore from dedicated mining outposts back to your iron smelter. You build 2 ore outposts, and you set up 2 trains, 1 for each. The two trains have a similar schedule; one goes from Iron smelting 1 to Iron ore 1, and the other goes to Iron ore 2. This works fine.
However there are some problems when you want to expand your production. You want to just copy-paste Iron smelting 1, and have half the ore go to Iron smelting 2. Now you need to start manually reassigning trains, trying to balance the throughput of the mines, and what else. If an iron mine runs dry, then you need to rebalance the whole system, reassign all the trains from that station, and have some omniscient overview of all the different routes your trains are running.
With more mines and more smelting and more trains, this management becomes an incalculable problem, and frankly it is not fun (opinion).
There is a nice solution, which works (almost). That is to name all the ore stations the same, and all the smelting stations the same. When choosing a destination, the train can go to any of the train stops with that name, which means:
However there is a small issue with the system, that completely breaks the idea. The trains are not clever. They will path to an arbitrarily chosen train stop with the correct name, based on destination distance and a few other factors. This means that it can easily happen that all the trains end up only servicing 1 iron ore pickup, while there are other outposts full of ore with no trains coming to pick it up. You can somewhat relieve the issue using the circuit network to enable and disable the train stops, but it is only a half-measure. For instance you can still end up with 10 trains rushing to a single small iron ore pickup, which can cause the trains to queue on the mainline and jam everything.
It is pretty simple, as good solutions typically are. You can set a 'Trains limit' in the train stop GUI, and the train stop keeps track of how many trains are in the station or on their way to it, which we call a reservation. When a train is choosing it's next destination, it will check the limit of all the stops with that name, and if a train stop has too many reservations already, it will skip over it. If all the potential train stops are full, the train will just wait.
This pretty much perfectly solves the problem with naming all the train stops the same, and also solves a few other potential annoyances. For instance, previously your Iron smelter stacker would need to be big enough to fit all the iron ore trains at once, because you couldn't be sure that they wouldn't all return at the same time. Now you can set the train limit of the Iron smelting train stop to the maximum capacity of the station, which means you can build a smaller stacker, and be certain that it will never become over-crowded.
The train limit is also controllable with circuit network, so there are even more possibilities. One idea is keeping the train limit set to 0 until there is a full load of ore available at the station. You can also read the current number of reservations, which will have its own interesting uses.
There is an edge case we had to solve while working on the feature, what happens if the limit is lowered while a train is already on the way? Our first idea was to force all the trains that are on the way, to repath and find a new destination. This works in many cases, but if there is no train stop it could path to, it would end up stopping and waiting in the middle of the tracks, causing untold economic damage.
So we decided that even if the limit is changed, any trains with a reservation will still go there. This means it isn't strictly a 'hard' limit, but we think it is a good thing, as setting the limit to 0 provides an alternative way to control train behaviour compared to when the station is disabled. Basically the train will only consider the limit when first deciding which stop to path to, after that it doesn't care if the limit changes.
We also had to deal with the 'No Path' warnings. If all the train stops were full to their limit, the train would show 'No Path', which isn't very intuitive for the players. So when the train can't find a path due to the train limit it will show a special warning: 'Destination full'.
To an outside observer, this really may just seem like a tiny little thing, but for us it is one of the most exciting features of 1.1. I think it is also quite telling that something like this has been missing for a long time, given the popularity of the Logistic Train Network mod. While the train stop limit isn't quite as powerful as the mod (understatement), it is going to open up many possibilities and add a lot of interesting gameplay oppourtunities.
I don't know if I am alone in saying, but I like it when the rules of a system are very simple, and the complexity emerges from the interaction of these very simple systems. I think the train limit is a perfect example of a simple rule, that will lead to really interesting and complex behavior. I can imagine just riding around on a Iron train with a simple "Pickup Iron -> Dropoff Iron" schedule, and it driving me around the whole factory as the chaotic interaction of train stop limits and other trains means each time it needs to travel somewhere else. I can imagine also a lot of fun design considerations will be needed when building such a rail network, where the traffic is less predictable than a 'Static route' system.
The tips and tricks have been a feature of the game for a very long time. They began as a way to explain things to the players that were not explained anywhere else. The iconic example is the 'Alt-mode' tip. Playing without Alt-mode is painful, and even more painful to watch, so we had to tell the player somehow.
When I say early days, I mean the early days, before even the indiegogo campaign. The first implementation of the tips was straightforward, but a bit rough.
The tips and tricks GUI in version 0.6.4.
The initial design:
It got the job done, but it needed some development as with the rest of the game.
Over time, the tips and tricks fell into a dark corner. It was always low-priority, and wasn't clearly a 'Graphics' or 'Programmer' task to improve them, it was something in-between. So that is where I came in, and took the task of making some improvements.
The tips and tricks GUI in version 0.16.51.
First improvements:
At this point we shifted focus to the other 'tutorial channels' as we were hoping that the new mini-tutorials and NPE would mean we don't need as many tips. We think it is better if things like item usages are explained in the item tooltip, rather than in another GUI elsewhere.
Apart from some GUI style updates, the tips and tricks were not changed significantly for the next few major versions.
On the approach to 1.0, I took a last quick look at the tips and tricks. The tips are one of the first GUIs the player sees when they start Freeplay, so I wanted to give them a last lick of paint before the full release.
The tips and tricks GUI in version 1.0.0
The improvements this time were the nice last finishing touches to bring the Tips and tricks to their final form.
So then that's that right? I finally rest, and watch the sun rise on a grateful universe...
Even before 1.0 was released, I was inspired by the Mini-wiki found in Krastorio 2, and the Informatron mod.
The main spark, is the index of topics. It solves many problems:
However with the deadline of 1.0 approaching and not wanting to expand the scope any further, I just let the idea brew in my mind... until now.
A picture is worth 1,000 words, and in this case, it is very true. So lets start at with that:
Lets go through and explain some of the initial changes:
An issue remains, an issue that is small, but in the long run and with compound interest, it becomes a big source of pain. The problem is that the Tips are still using images, which means they become outdated as we update things. We have retaken all the screenshots many times now over the years.
So what can we do about it?
In this case, a GIF is worth 1,000 images, so lets start with that:
What you're seeing is a GIF (technically an .mp4) on a webpage, but we are not putting GIFs in the game. What the GIF shows, is the Tips and Tricks GUI live rendering a real simulation of the entities inside the GUI. This marvel of technology is a divine gift from the very top (kovarex).
The simulation widget solves quite a lot of the initial problems with using screenshots/images, but we can go even further.
We can use the simulation not just to show a factory environment. Using the Lua scripting, we can create entire scripted scenes and demonstrations. This is much more effective in many cases. For instance seeing the building preview, the mouse movement, and hearing the 'real sounds', makes the tip much more meaningful.
We are left with another problem, we still have the mini-tutorial GUI. So it is a weird and awkward situation that some things are explained in the Tips GUI, and other things via the mini-tutorials.
The mini-tutorial GUI is quite a challenge in itself, and it has a lot of similar problems to the old Tips and Tricks GUI. The mini-tutorial 'images' are just 'related' technology icons, with the 'related items' underneath. The text gives a short description of what you might expect from the tutorial.
It would be pretty nice if the mini-tutorials could have the same sort of features as the tips and tricks, an index, nice big images inticing the players to click the 'Play tutorial' button... etc.
So what if, we just somehow put the mini-tutorials in the tips and tricks GUI? It makes a lot of sense, and unifies the communication channel. You know now that if you need help with a topic in the game, there is one place you should look for some guidance, the Tips GUI.
The mini-tutorials had some nice features or their own, they would only show if the player had met some requirements, and would be suggested to the player if they performed certain actions. For instance the Train tutorials would only show after you have researched the railway technology. If we unify the two concepts, we can use the unlock and suggestion features for the Tips and tricks.
So we combine the functionality of the two systems. Mini-tutorials are still the same, but they are presented inside of a Tip, and we hook in the suggestion and dependency system to the tips. We added a 'Mark as read' button, and Tips will show once the dependencies are read.
We see this new unlocking and recommendation system as one of the more important improvements. It means the tips and tricks GUI starts with only the nescessary tips, and as you progress in the game, relevant tips are unlocked and shown to you. This is very similar to the way the game starts with only a few recipes, and the more complex aspects are unlocked over time.
Once last minor issue with the old tips and tricks, is that they were 'hardcoded' in a sense. They were loaded from a very specific JSON file in the core data directory. That means that it was not possible for mods to add or change any of the tips.
It is only natural then with this update and modernization of the tips, that we open up the system to modders. Internally the Tips work like any other prototype, so it is super easy for a mod to add their own entries.
When adding the new tips, it was tempting to make tips for all of the things. However after some consideration, we decided to not go too far this way. We don't want the tips and tricks to become a 'Factoripedia' or 'In-game wiki'. In general, the items and entities and general mechanics should explain themselves in more direct ways, such as the entity tooltips.
What we want, is for the tips and tricks to explain mechanics and topics that are more complex, or hard to explain somewhere else. With that in mind, we decided on a few loose categories:
Importantly, we should really only explain things that players actually don't get. I have never heard a complaint that someone doesn't understand how solar panels or accumulators work, so putting these into the tips and tricks would be just bloat, even if it technically fits the criteria.
We are quite happy with the result, the tips and tricks GUI was always one of those paradoxical systems that was both extremely useful and terribly ineffective at the same time. We really hope all the effort we have channeled into it will help.
Speaking of help, we need your help: What kind of tips would you have found useful when playing the game? Searching TIL on Reddit can be a source of inspiration, but it is still hard to compare the importance of individual independent Reddit posts, and also a lot of them are outdated. So, if you want to give us feedback, the FFF discussion is the best place (yes we do read Reddit).
