A really strange debate started as a continuation of FFF-238. I insisted that the button order should obviously always be OK Cancel, as in any UI I see around.
But little I knew, that this is actually specific to windows, and on Linux or macOS, the order is reversed:
Eventually, we figured out, that we are not the first one trying to solve the problem.The solution we are now experimenting it sounds like a bad idea: "Make it so much different and Factorio specific, that the way it is done in your specific system will not interfere with your muscle memory". Which brings me to the load game dialog mockup:
Load game dialog
The load game dialog is currently the first dialog we are trying to implement with the new tileset and the mockup Albert created recently. The mockup looks like this:
The idea is, that all the dialogs will have this flow from left to right, on the very left, you go back, on the very right, you continue to the next window. The same logic would be consistent in all the dialog windows. Options for example, have only the Back button in 0.16:
It is currently quite weird, as it is not clear whether it is confirm or cancel. Actually, if you press Escape you exit the options without saving it, but if you press "back" you confirm the changes.
So these will also have cancel on the left and confirm on the right. Escape is the same as clicking back.
Please note, that all of the pictures are work in progress.
The map generator GUI
Hopefully you are not getting tired of hearing about the GUI, because this game sure has a lot of them, and the next one to talk about is the Map Generator GUI.Since we will have high-resolution spreadsheets for the GUI, all the mockups below are done on 200% UI scale, so they are scaled down on this page. You can click each image to see it in full size.
You will notice things were moved around quite a bit. The seed and the replay toggle were moved to the top since they are not part of the preset. Then the preset dropdown, the reset to default button and the description, which are visible at all times so you know what you are editing. Everything inside the tabs is part of the preset.
A new tab is the Enemies tab. The generation settings (Frequency, Size, Richness) are moved from being hidden in the terrain settings, to it's own category. Also the important Peaceful Mode is right at the top.
Finally the advanced tab contains the rest of the settings. Map width and height will now also be part of the preset.
The map exchange string can help you save all your settings in a string, but more importantly to share it with others. Clicking one of the buttons opens an in-window pop-up. The pop-up can be closed just by clicking outside. Player can use the "copy to clipboard" button, but can also copy directly from the textbox.
Now for the neat part: the map preview will be part of the map generator window. Clicking the "Preview" button expands the window (possibly with some quick animation). You can then change the settings as you like, then click Update to see the new map. You can have the map update automatically as you change the settings, by enabling the option. "Real-time update" is off by default since the preview generation can be a bit slow, and having the preview constantly flickering as you change the setting would be pretty annoying.
Notice that the "Preview" button has a warning icon next to it (in the images above). Hovering over it will give you a warning that the preview can spoil the exploration part of the game and should be used to understand the settings. My hope is that the majority of players will open the preview, play with the settings, then close the preview and re-roll the seed before pressing play.
(click to view full size)
We plan that almost every widget in this GUI (and the of the game) will have tooltips briefly explaining what everything does, since for example not even us developers know what Enemy base Richness actually does any more. As a bonus, here is a mockup with all the ores showing their richness.
As always, let us know what you think on our forum.
Being brought in to create content on a very mature project has been an interesting experience to say the least. One of the first things I did was analyse the features of the game and which kind of player the game currently supports. The obvious thing is that Factorio Freeplay strongly attracts and engages players who enjoy an open-ended sandbox type of game. Achievement statistics show that only about 11% of players on Steam have ever launched a rocket, which currently means 'won the game'.
What about the other player types? Well for those that are new to the game, or unsure if they are interested, we will have the New Player Experience. This is a free, combined tutorial and demonstrator mission which we discussed in FFF-241. But what about those that prefer a guided experience? This is the sort of player who wants to play the game, and experience all of what it has to offer, but wants to be taken on a journey. For these players we have the campaign.
Why do we need a new campaign at all? We find that the current campaign:
Does not include all the Freeplay content as it currently ends after Advanced Circuits.
Severely limits player investment by forcing a new factory to be built each mission.
Does not convey the feeling of loneliness that the Freeplay does.
Is showing its age visually, as it was made before high-res textures and the terrain rework.
To solve these issues we have set about designing new Campaign elements to act consistently to provide the player with a guided experience all the way from Science pack 1 to Space science packs.
The first step to achieving this is to have the map border expand each time the player completes a section of the main 'quest line'. This means that the player never loses any of their progress, and as long as these transitions are presented in a smooth way, the jarring effect of the old level restarts will be removed.
Having a continuously expanding map presents many other challenges, but we are confident that it will be worthwhile. This style of level will fit with the style of Factorio much better.
Such a map should also end up being as huge as a regular Freeplay environment so as to better place importance on exploration. Exploration in Freeplay is generally player motivated, such as when you are almost out of iron and need to find that next big patch. In a guided experience, letting the player know that there is something out there can give them impetus to dive into the unknown. This brings us to technologies.
Now that we have removed level transitions, we have also shot ourselves in the foot. How else will we deliver the technology tree in chunks? Simply making the entire tree available from the start of the game will cause all sorts of balance issues. In our NPE discussion we stated that new recipes should only be given to the player via research. In the campaign, unresearched technologies will only be given by moving to given locations on the map. These would include some non-generated terrain and pre-placed factory structures to help to player see where they are. These could also help to show concepts and workable designs, one thing that the current campaign does do well.
Science packs and technologies
When designing the campaign, we look at many things in the game very closely and often we start seeing some problems.
One such problem that has been confusing players for a long time now is the fact that the most important ingredient for progression - the science packs - are unlocked in arbitrary technologies. On top of that we changed those technologies a couple times already, so remembering if that elusive blue bottle is unlocked by battery or advanced electronics just adds to the confusion.
So in 0.17 we are going to add science pack technologies which only unlock that new science pack, making it clear in the tech tree where you get them and what they will lead to. Doing this properly requires a bunch of changes to the prerequisites of many technologies, but those are generally just cosmetic changes that don’t actually have any bigger impact on the game.
Here you can see the technology tree for the Logistic system. The GUI rework is being worked on in parallel, so this will actually be much nicer to look at in 0.17.
Production vs. High-tech science
When we were designing the High tech and Production science packs for 0.15, the purpose was to create a choice for the player whether after Science pack 3 they want to continue with a more 'production' or 'high tech' oriented method. Looking back, the idea is definitely good, but we want to make it more clear.
One of the big obstacles was that the Power armor mk2 required level 3 modules, which are a great candidate for production science pack - but Power armor mk2 is meant to be in high-tech. That made us only put the productivity module to the production science pack, but productivity modules without beacons and speed modules aren’t all that great, so you would still need the high tech science pack to make full use of productivity modules.
The resulting solution is that we changed the recipe of Power armor mk2 to require level 2 modules (which still require just Science pack 3) instead of level 3, and moved all of the level 3 modules to production science pack. Additionally the beacons are now unlocked with Production science packs without the need for High tech science packs. The total cost of Power armor mk2 is roughly unchanged, we just tweaked the numbers of modules it requires. These changes should already make both of the science packs offer quite appealing benefits, and it’s not so clear that one science pack is superior over the other.
Because of the new technologies for unlocking science packs, it is really easy to see what options each pack unlocks.
Overall we want to keep the campaign and the Freeplay technology trees exactly the same to avoid confusion, so any change we make, we make in both - which should give the Freeplay another layer of polish.
As always, let us know what you think on our forum.
Mobile users may see that the website is significantly easier to read today, that is all thanks to our new Python developer Sanqui. Apart from making out website more mobile friendly, we have a lot of tasks on the backlog that he will start working on soon.
His first major task is to speed up and optimize the matching server, with which he is already making some progress. A bigger rewrite for the long term is underway, but in the last week he has reduced a lot of the slowness and timeouts people were seeing during peak times. He will be taking over our database management and web administration from HanziQ, as well as spending time cleaning up our codebase, maintaining our web services, and developing features for the mod portal.
Plural form localisations
Plural localisations are needed here and there in Factorio. For example, when the time is specified, it can be either 1 minute 5 seconds, or 5 minutes and 1 second, so there needs to be some system to select the correct word depending on the count.
In 0.16, we have this very specific custom system of specifying some of the translations by 3 different forms, while very specific code selects the correct one depending on the corresponding number:
English:
minute1=minute
minute2-4=minutes
minute5+=minutes
The English translators might be quite surprised, why do we need 2 different translations for plural of minute? The Czech people reading will understand, as the Czech localisation file looks like this:
minute1=minuta
minute2-4=minuty
minute5+=minut
Yes, we (Czech people) have a different kind of plural for count 2,3,4, than the other plurals.
This made it clear, that having different translation key for every possible form for every language would be too crazy, so we invented something more generic. In 0.17, the translation of X minutes (the number is now included in the translation to allow to put it on different position, or to add some other word somewhere) will look like this:
minutes=__1__ __plural_for_parameter_1__[1]__minut__[ends in 01-19]__minute__[rest]__de minute__
etc.
Progress on engine modernisation
The rewrite of the rendering framework goes well. We are at the point where the game looks exactly the same (with minor fixes to line rendering) as our main 0.17 branch, and the only major thing that is missing is proper error handling - for example, we don't want the game to terminate if a screenshot command fails for whatever reason. I was surprised at how many things we had to rewrite, but we took our time, and I think it is already worth it. The game rendering performs significantly better (well, at least on CPU side of the pipeline for now - more on that in some future Friday Facts) in both OpenGL and DirectX.
Speaking of which, some people were wondering why do we even bother with DirectX, and not just to use OpenGL everywhere. The reason is Windows is still the main OS for PC gaming and for some reason, we can't squeeze as much performance from OpenGL as we can from DirectX (we are seeing about 30% more time spent in calls to OGL as opposed to D3D). It also seems the OpenGL driver quality is all over the place. We already ran into the problem where our first implementation of building sprite atlases worked great on Windows and macOS, but was so inefficient on Linux it took over half an hour for the game to load.
We are actually trying to design the new rendering around architecture of current-gen APIs - Vulkan/Metal/DirectX 12 - and in future we would like to create Vulkan and Metal backends, but we are focusing on older APIs first as a large portion of our current player-base doesn't have Vulkan capable hardware. By using OpenGL 3.3 Core and DirectX 11 feature level 10.0, we should cover 99% of our current players (according to our Steam hardware survey statistics). These APIs should be supported by any dedicated GPU manufactured in the past 10 years, and integrated Intel HD Graphics since Sandy Bridge. We'll still leave 1% of players behind, so they are going to be stuck with 0.16, similar to when we dropped 32-bit support, but everybody else should benefit from better performance and hopefully a better looking game eventually.
As always, let us know what you think on our forum
Underground belt marked for deconstruction no longer connects to other underground belts.
Bugfixes
Fixed some cases of fast replacement by underground belt. more
Fixed corrupted config.ini in Steam cloud would prevent the game from starting.
Fixed that using "Save and play" feature in the freeplay could specify the official freeplay map to be always that one forever. more
Fixed underground belt connection overlay when hovering over another underground belt. more
Fixed a crash when mods define empty result items. more
Fixed a crash when switching games and joining quickly in the server browser.
Fixed that clicking rail planner with no available path while recording replay invalidated all other actions of the replay. more
Fixed a crash that would happen after opening a library blueprint that contained only entities from a disabled mod. more
Fixed LuaEntityPrototype::braking_force return value. more
Fixed LuaPlayer::ticks_to_respawn would read in seconds. more
Fixed certain type of energy source migrations. more
Fixed rare possibility of crash when two trains crash into each other. more
Fixed a rare crash that occurs when train collides in a way, that its position is reserved back while approaching closed signal which caused path recalculation. more
Fixed PvP error when setting map height to 0. more
Fixed construction robot tutorial breaking when removing the radar from the storage chest. more
Fixed crash when adding train station to a train while the train is modified (added/removed rolling stock). more
Fixed that destroying part of a cliff with tile ghost under it destroyed the whole part of the cliff. more
Fixed browse games dialog problems with the active game not being updated while searching. more
Modding
Added support to set ReactorPrototype::neighbour_collision_increase which controls how much a reactor extends when connected to other reactors.
Scripting
Allow technology_price_multiplier to be less than 1 by script/scenario only.
Added support for localised strings in LuaGameScript::write_file.
You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.
The process of the GUI re-design is moving slowly but steadily. By making new mockups, re-thinking old mechanics, and with the proper feedback from a different range of people, the parts are falling into place.
I'm starting to feel very confident with the actual general contrast and font sizes. Also the conversion from high resolution to normal resolution is working just fine. These subjects are very important to move forward with.
Below you can see a demo of the current state of the new GUI. Not all the widgets are shown yet, but this document is helping us a lot in order to define the future elements.Seeing the big picture makes it much easier to tweak them altogether with a better coherence and consistency, not to mention for testing any kind of font, specifically non-latin characters sets, a subject that I personally have not paid too much attention to yet.
This document is being used also to create the general tileset and see how it behaves in the engine. This is a work in progress, and we are tweaking details constantly. Many things will change during the process. Overall here you can see a sneak peek of the Factorio GUI to come.
I want to also mention that we are actually taking care of the 8% of the population who has some sort of color vision problems. This subject is still very new for us, but we are without a doubt researching solutions to different conditions.
New office
The moving to the new office went better than expected, and with the new carpet, it feels cozy.
We are currently using approximately 40% of the available space, so there is a room for growth if needed.
