Hi all, sometimes, writing FFF feels like spitting out blood - there is simply very little to write about. Yet the Factorio blog subscriber crowd is there and waiting ... Sometimes it is the opposite and there is abundance of interesting topics available. Today it is the latter case. Enjoy!

Factorio Massive Multiplayer

So all the effort that Kovarex put to rewriting the Multiplayer for the pure server-client model (communication wise) with added speed optimisations and minimisation of the data sent over network has paid off royally. Surpassing our wildest estimates it has been actually shown that the latest 0.14 (still experimental atm) can support a couple of hundreds of players in the game (I believe the current record is about 400 players) while still being playable. If I remember correctly, the best case scenario (when Kovarex started with changes) was hoped to be 50 people in the game ... Arumba (with Steejo and friends) has started a new stream series where he creates an open game and a bunch of people get together and start building a factory. Below is the first episode which was streamed on Tuesday. There were about 150 people online at one point I believe and still the game was running smooth. Factory grows up really fast (though often in uncontrolled ways) with that amount of players. I personally find interesting all the "social / group" peculiarities arising from this kind of event - ranging from how to organise such a crowd to work together all the way to persuading people not to shoot each other or build useless ghost entities all over the place (because "it is pretty"). https://youtube.com/embed/LeHEj_sEKnw The series continued yesterday night with couple of people from the office (well from their homes because it was at 2 a.m. local time) joining as well - namely kovarex, twinsen and posila. This time there were some technical problems - server overload / lags / desyncs - simply because there were crazy amounts of people (those mentioned 400 online players). But it is amazing to see what the technical limits of the game are (could it be even more than 400?). And as a bonus you can hear Twinsen / Robert joining the skype chat with the organisers and sharing some of his insights. I believe Arumba plans to continue with the series (though restricting the amount of people to a reasonable amount) and see how the factory develops. So check out his channel if you are interested in watching / playing with many players. Below is a screenshot from the imgur gallery created by one of the players based on the second ("the 400") game - to give you a feel of what you are up to.
We shall see, but MMORTS could be another area Factorio will venture too. The technical background is more or less there. Now it might be the time to come up with scenarios / game modes that build on the possibility of having hundreds of players in the game. We have already started playing with this with the Team Production Challenge (that is a bit less massive) mentioned in the previous FFF ...

UI rewrite

And now for something completely different. Making a game is a broad topic and often involves elements which end up being overlooked (people often don't notice things until they are not broken). One of the areas in this realm is IMHO good gui design and layout. Honza recently took the challenge to improve our current gui code and prepare it for further gui improvements that he will work on together with Albert. So below he writes about what he has been up to. Factorio is a dialog-heavy game, so the GUI code needs to be easy to write.At the same time, we want complex GUI layouts that don't break under different translations and mods. With that in mind, I've been cleaning up the internal GUI implementation.While the old code sometimes needs a lot of persuation to do exactly what we want,the new shiny code will use a two-phase layout algorithm:

• All of the GUI elements look at their contents and report their optimal size and stretching potential.
• GUI containers take whatever space is available and, based on the reports, tell their sub-elements how much they should grow or shrink.

Looks simple, but it should solve most of our problems with nested containers. We also need to be able to override the automatic stuff: limit the minimum or maximum size, grow only in discrete steps,constrain some elements to be the same size, or just set the position and size manually. Let's look at a pretty ASCII-art example. The elements A and B start the same, but B grows twice as fast and has its maximum width limited:
Another example: Here the vowels may not grow, but the width of each block must be the same:
The last one: we have two buttons that can't stretch, but one must stay centered and one right-aligned (assuming they won't overlap).There's a ghost on the left side with the same size as button 2 that makes it possible:
The GUI containers will also get an overhaul: right now we're using a one-size-fits-all layout with automatic row breaking,which is overkill for most uses. The new GUI will use simple rows, columns, and the occasional table. There are other things in the works: improved GUI scaling, rich text, data-driven layouts, better line breaking for long texts, or support for right-to-left languages.And when all the boring internal stuff is done, you can look forward to a complete GUI facelift.

Blueprint Library

While 0.14 is getting stable we are already working on 0.15. One of the bigger features there would be the blueprint library. The idea is to allow blueprints (and blueprint books) to be stored outside of the players inventory - in a blueprint library. This way the blueprint (or book) can still be accessed even if player actually removes / loses (i.e. when dying) the item from his inventory. The library will be accessible via a global dialog (in a similar fashion like overview of trains / production statistics / etc.). At the moment we plan to have three basic library sections:

• Blueprints stored locally in the game. Here the use case is simply not to lose (as mentioned above) blueprints for the current game when their respective items are lost.
• Player's personal blueprint collection accessible in all of his games. Here we are pretty sure (=)) that players will build their own collections of favourite setups which they use over and over.
• Access to other players' personal blueprint collections in multiplayer games. This is the same as point 2 but for multiplayer.

The work on this feature is at the moment in progress so it is a good idea to post ideas (or link existing ideas - hello Factorio ideas & suggestions overflow) on the topic. There will be more detailed information coming in the future (both on the user side as well as challenging technical aspects - yes everything is more work than expected =))) when the work has progressed. The promise of the blueprint library is that it should make blueprints even more useful by removing frustration from losing existing blueprints and repetitive work of creating the same blueprints over and over again. Also who knows, maybe we end up with a Factorio blueprints portal - something like a global database accessible to all the players. That would be an interesting way to share the setups.

Terrain news

In one of the previous FFF editions we have shown first attempts on a new terrain, the red desert. Jurek is still working on this and today you can see how he has progressed. It is not yet finished as we will be tweaking it and adding specific doodads and patches. That means it should get only better=)
And now in an action with some entities:
If all goes well (that is a big if) you can look forward to a new pump connection to liquid wagon preview in the next FFF episode. That is what Albert has been up to recently. As always, if you have any comments or otherwise, please let us know on our forums.

[ 2016-09-16 15:57:14 CET ] [ Original post ]