Friday Facts #277 - GUI progress update

[Jonathan88]

I used to play quite a bit of the wave defence, but it got a bit boring after a while - I could just blueprint the entire base just before it was destroyed and start again, immediately rebuilding the factory to that state at the beginning of the next playthrough.

The solutions seems simple - add an option to either:

• Play the/a preset map
• Play a new random map
• Play the same (random) map as last time

[Jon8RFC]

If wave defense works best on custom-tailored maps, there's a third idea--make it into a regularly-updated scenario.

Mario kart wii tournaments (not sure if wii-u and switch do the same) had monthly tournaments on tweaked maps. It could give you something to keep busy, and give users a sense of keeping the game fresh, directly from the developers, even after it's "finished". It doesn't have to be perfect, but tuned just enough so that it's not a distater.

Sure, someone random could do their own version and offer their own scenarios/maps in a mod, but that approach in games is often never as collectively appreciated or utilized as much as whatever comes officially from the developers.

[ske]

Ah, I have a great idea for your blueprint UI that would save a lot of time: Make it available through command line only.

Sounds crazy? Yes, yes, it does. But think about it again. You are teaching people automation and the command line is king of automation. You are trying to fit a square peg in a round hole if you try to overuse the graphical interface and don't use superior tools. So, why not give the king what belongs to the king?

[ske]

Regarding the scenario/random map topic, there could be a middle way.

Regarding the blueprints, you could counteract these to some degree a) with randomly switching resource fields in the starting area (copper and iron trade places). b) by inserting non-removable obstacles in certain areas (e.g. 5% small water lakes everywhere). I think you would have to define some parts of the map that stay the same and some parts that get randomized. This shouldn't be too hard with scripting.

Regarding larger areas of the map, I think that we could allow more randomness and use the generator there. Maybe with similar settings, so the changes won't be too big every time.

Is blending of a scenario map with a randomly generated map possible without creating too hard seams?

[pingger]

Hi,

the Settings GUI is one of the most important GUIs of the game. Taking me as an example:
I even quit tutorials, just to get to the settings first, to make sure everything is configured as I want it to. Specifically graphics, sound, Usertracking (Data Protection,...).
If I find the Options to lack something very important (e.g. in some Unity based games, the lack of a 'disable telemetry' button, or Motion Blur/Bloom (as I get Motion sickness from both)), I'll probably quit the game and never touch it again. And (if possible) get a refund.

Not all games need all settings. In Factorio a resolution setting isn't necessarily needed, as it can be started in a resizeable window and doesn't need lower resolutions for better performance since it can even run years old hardware without issues.

Some games hide those 'important' settings behind an 'Advanced Settings'-Mode, but as long as the Settings GUI allows me to adjust the settings in a simple and predictable manner (and does not force me to restart after each and every setting...) I'm fine

Greetings

[rstarkov]

You're doing great work with UI scaling! I do wish you wouldn't limit it to 200%. Consider a 4K screen in a 13" laptop, like the Dell XPS 13. It's about 330 dpi. A 32x32 icon scaled up by 200% would still be TINY: approximately 5mm across.

I feel it's OK to leave the icons at 64x64 and simply allow them to be stretched a little. Just don't put an arbitrary limit of 200% on it...

[Jon8RFC]

Ah, I have a great idea for your blueprint UI that would save a lot of time: Make it available through command line only.

Sounds crazy? Yes, yes, it does. But think about it again. You are teaching people automation and the command line is king of automation. You are trying to fit a square peg in a round hole if you try to overuse the graphical interface and don't use superior tools. So, why not give the king what belongs to the king?

I think I understand what you're getting at, but my favorite part of a game has never been when I have to drop down the console (and stop playing the game to google a command for which I don't know how to describe exactly as others have previously posted, asking about) to do something which isn't readily-available. I do that already when I want to test a potential bug, and struggle to find the commands for factorio in this very forum.

There's a subset who appreciate and enjoy additional inconveniences and/or customization. I enjoy that availability when I have no other choice, but I don't like ditching a UI for commands in a game. Factorio already has plenty of handy gameplay tricks and keyboard shortcuts to learn, even when you've played for thousands of hours. I recently told someone in multiplayer "if someone ever says they know factorio entirely, they're either lying or misinformed".

I certainly don't want to play monopoly with my nephews by saying "random number...car to spot 1...collect 200...purchase 60...exit" without a board or pieces, and only a piece of paper and a pen to keep records. Sounds pretty boring (and how can I diplomatically say "pretentious"?) to me.

[authorized411]

This way, you get feedback faster.

Part of the reason Factorio experimentals are so stable is precisely because they want to avoid the excess of user-feedback on issues they can see themselves. When there are obvious issues and a storm of feedback, the noise can slow down progress!
...

v0.12.35 - 35 updates
v0.13.20 - 20 updates
v0.14.23 - 23 updates
v0.15.40 - 40 updates (track laying and science changes)
v0.16.51 - 51 updates (map gen, science changes, etc)

They get stable, they don't start that way. Iterate.

There may be issues and suggestions, but in general the devs have thought through their designs very carefully

Yes but there's a difference between paper, power point, actual implementation, and more than X developers who know each other's style of play, quirks, habits, etc. The faster a alpha/beta can reach the target audience, even a select one, the better.

Iterate. MVP (minimum viable product)

There is no financial or operational imperative to release in this scenario though. It's not like new graphics drivers are released that require an update to work or similar.

Yes there is to both. The faster a alpha/beta can reach the target audience, even a select one, the better. The faster you'll know you're on the right track. I know that the game's vision and overall design will take precedent over any feedback. Question is, how much of that feedback goes along with the vision and overall design? What if you can get that information sooner than later? It happened in v0.15 when the purple science recipe was changed in the middle before that version was considered stable.


All I'm saying here is that this FFF reads like they are going to hold up the 0.17 release, which already has game play changes in it and needs experimental testing and feedback, for GUI changes. GUI changes in the grand scheme of 0.17 is minor. This FFF makes read like it'll be another quarter due to the GUI changes before we get our hands on the game play changes. Players are use to the current UI. Why not have a v0.17 two-part release: Game play to game-play stability, then quality of life (GUI changes) as secondary. As I mentioned in my original post, giving the player an option to switch off the new GUI would allow them (developers) to focus on game play stability OR GUI stability.

For example, if there was a problem with either, fixing game play is primary so they (developers) could recommend using the old GUI until the game play is fixed. Once game play is fixed, then they (developers) can focus on the GUI issues. During the whole time in this scenario, the player hasn't been forced to use the new GUI and can continue to play using the other working features of v0.17. The player has not lost access to something due to a GUI issue in this case.

[micromario]

Moving to 64x64 item sprites sounds like a lot of work for modders.

[bNarFProfCrazy]

There may be issues and suggestions, but in general the devs have thought through their designs very carefully

Yes but there's a difference between paper, power point, actual implementation, and more than X developers who know each other's style of play, quirks, habits, etc. The faster a alpha/beta can reach the target audience, even a select one, the better.

Iterate. MVP (minimum viable product)

There is no financial or operational imperative to release in this scenario though. It's not like new graphics drivers are released that require an update to work or similar.

Yes there is to both. The faster a alpha/beta can reach the target audience, even a select one, the better. The faster you'll know you're on the right track. I know that the game's vision and overall design will take precedent over any feedback. Question is, how much of that feedback goes along with the vision and overall design? What if you can get that information sooner than later? It happened in v0.15 when the purple science recipe was changed in the middle before that version was considered stable.

No having only a subset test changes is unfair to the other players. Have you heart about Satisfactory? Its anoying that "everybody" except you and a few others got an alpha key. Bugs are annoying. Do you think you would drool over Factorio if it was slow or buggy?

All I'm saying here is that this FFF reads like they are going to hold up the 0.17 release, which already has game play changes in it and needs experimental testing and feedback, for GUI changes. GUI changes in the grand scheme of 0.17 is minor. This FFF makes read like it'll be another quarter due to the GUI changes before we get our hands on the game play changes. Players are use to the current UI. Why not have a v0.17 two-part release: Game play to game-play stability, then quality of life (GUI changes) as secondary. As I mentioned in my original post, giving the player an option to switch off the new GUI would allow them (developers) to focus on game play stability OR GUI stability.

For example, if there was a problem with either, fixing game play is primary so they (developers) could recommend using the old GUI until the game play is fixed. Once game play is fixed, then they (developers) can focus on the GUI issues. During the whole time in this scenario, the player hasn't been forced to use the new GUI and can continue to play using the other working features of v0.17. The player has not lost access to something due to a GUI issue in this case.

AFAICT they also replaced the graphical engine they use under the hood. This sounds pretty much like rewriting most components. There is no longer a working GUI version you can use. And if every released game including AAA titles had as little bugs as factorio has during its experimental phase, then the world would be a better place. Don't you feel the pain if you build n hours on your map and then the game just crashes and everything is lost?

[bman212121]

Will the UI scaling have options to go smaller than 100% as well? Playing the game on a 720p monitor the UI is so huge you run out of screen real estate. Like someone said, It would be nice if there was a fairly large scaling option, like 25,50,75,100,125,150,175,200,250,300,400 percent. I'm kind of wondering how difficult it would be to borrow an idea from the web and just use different icons for different scaling sizes. It's not uncommon to actually have made the same logo in 3 different sizes, and the rendering engine simply picks the most appropriate one for the situation. So you could keep the 32 x 32 resolution, but also have 64 x 64, and 128 x 128 sized icons. Then the rendering UI can simply pick what would work best.

An example would be the rendering engine can just calculate that 100% on 720p = this many pixels, and if the number of pixels goes above a certain threshold bump up to the next texture size. If you're trying to use 400% on say an 8K monitor, you probably want 128 x 128 starting icons. Using 50% on 720p 64 x 64 icons might have too much detail in them to really work, but the old 32 x 32 should look great.

As for mods, it should be easy enough if the mod maker only specifies they have 32 x 32, then the game render only uses those icons. There really shouldn't be a need for mod makers to have to change the icons at all, and worse case is the UI could just double them to 64 x 64 if needed. (Or mod makers could just do the same) I think it would be better if they could also do the same though, and be able to supply 32 x 32, 64 x 64, and 128 x 128 icons if they desire. More work yes, but I'm concerned that even 64 x 64 really won't be enough for 8K screens. If you're going to re-render those icons anyway, you may as well render them at a few different resolutions so they will scale to future needs.

[theqmann]

Here's my idea for wave defense. Why not have a contest using the new map editor to create static wave defense maps and fold the top N into the game? That will give some variety without worrying on RNG for maps.

And on the item sprites, I think moving to 64x64 sprites for UI scale is missing the forest for the trees. People who use large UI scales do it for 2 reasons that I've seen. They are either running UHD (4k) resolution and trying to make the UI elements not tiny, or they have vision problems and need to make things bigger so they can read them (like large print books). As it happens, both of these apply to me. In neither of these cases would higher definition sprites actually provide almost any benefit. In the first case, they will be so tiny that you can't see the extra detail, or the vision is poor enough to blur the detail anyway.

[bman212121]

Here's my idea for wave defense. Why not have a contest using the new map editor to create static wave defense maps and fold the top N into the game? That will give some variety without worrying on RNG for maps.

I kind of like this idea. I think it would be more beneficial to the wave defense if it did have a couple of maps to choose from, but I wholeheartedly support being able to use random maps as well. Have a list of like 5 - 10 default maps, then an option to use the map generator if you want to roll your own. Like others said, using the seed ID would be handy, but that should be part of the map generator so it should work out of the box.

There are a couple things about wave defense I will say. #1 I didn't even know it existed until I stumbled upon it after like 600 hours of playing the game. I always just click into MP, and connect to server, so I never paid attention to the scenario button. I would have probably played around with it sooner if I knew it was there.

The other thing about wave defense, is that it's really, really hard. I can see if you were playing MP with like 4 or 5 players it could go better, but trying to solo it I made it to the same wave 3 times in a row, got frustrated, and I haven't used it again since. I'm sure if you used pre canned blueprints it would help get you farther, but I really wish you didn't have to do that. It would be nice if you could scale the difficulty a bit to make it more manageable if you don't have several friends or a but of pre made blueprints to help you win.

[zero318]

Even though a GUI update may seem "minor" to players, it's actually a big deal from a coding perspective.

Every single tick the game has to run the code to render the GUIs. Since the updated GUIs run on a new and improved system, the existing GUI code can't be used to render them. And until all of the GUIs are finalized in the new system, that means that both the old GUI code and new GUI code would have to be run simultaneously in order for the game to be playable.

Not only would that roughly double the amount of GUI code eating away at UPS, but the two systems might not even be compatible with each other at a fundamental level. And even if it could work, it'd make the codebase a mess just for something temporary. Worse, dealing with all the bugs that would inevitably cause would just slow down progress.

Considering that most of the gameplay changes are already available as mods, it's best to wait for all of the GUIs to be finished before releasing any official builds.

[authorized411]

Update: clarification below about how long since v0.16 was testable. This FFF provides frame of reference 016-stable

No having only a subset test changes is unfair to the other players. Have you heart about Satisfactory? Its anoying that "everybody" except you and a few others got an alpha key. Bugs are annoying. Do you think you would drool over Factorio if it was slow or buggy?

By "a select few" I meant those of us players who opt in to experimental builds, not a lottery of keys. Also, by target audience, well, google that if this response was in response to that.

All I'm saying here is that this FFF reads like they are going to hold up the 0.17 release, which already has game play changes in it and needs experimental testing and feedback, for GUI changes. GUI changes in the grand scheme of 0.17 is minor. This FFF makes read like it'll be another quarter due to the GUI changes before we get our hands on the game play changes. Players are use to the current UI. Why not have a v0.17 two-part release: Game play to game-play stability, then quality of life (GUI changes) as secondary. As I mentioned in my original post, giving the player an option to switch off the new GUI would allow them (developers) to focus on game play stability OR GUI stability.

For example, if there was a problem with either, fixing game play is primary so they (developers) could recommend using the old GUI until the game play is fixed. Once game play is fixed, then they (developers) can focus on the GUI issues. During the whole time in this scenario, the player hasn't been forced to use the new GUI and can continue to play using the other working features of v0.17. The player has not lost access to something due to a GUI issue in this case.

AFAICT they also replaced the graphical engine they use under the hood. This sounds pretty much like rewriting most components. There is no longer a working GUI version you can use. And if every released game including AAA titles had as little bugs as factorio has during its experimental phase, then the world would be a better place. Don't you feel the pain if you build n hours on your map and then the game just crashes and everything is lost?

I'm not trying to deny them (developers) from getting this big win. I know refactoring the GUI is huge for them. I want them to get this win. However, there are already tones of changes in this upcoming update. For myself and probably a lot of others, this FFF reads like it'll be a long time before we get our hands on v0.17. I think we're over a year since v0.16 was release and nine months since it was considered stable. That's almost year's worth of changes that the target audience hasn't gotten their hands on to test. I work in the software development industry. That scenario is extremely scary to me.

All I'm saying is, the current GUI works. Yes, they're not happy with the design of it and I cannot wait to use the new one. However, there are game play changes that are several months to almost a year old. None of the players have gotten to test them yet. They'll be a lot older and have yet to be tested by 1000s of players on 1000s of different computer configurations. The iterative thing to do is to have the oldest stuff (game play) get released while the newest, quality of life changes come after. Released at the same time is just going to cause a nightmare for everyone. Whether it is bugs or the release is still being hold up due to GUI refactor.

This FFF reads like 0.17 is going to be held up for a GUI refactor. Why hold up an entire release for a GUI refactor? A complete GUI refactor is another release.

Iterate.

Two-part release is all I'm saying. A GUI refactor is not low-hanging fruit. It is a big win, but with all the screens and how things need to interact, seems like a lot more risk to an already huge v0.17 update.

[Dixi]

I tried wave defense once, and found that it's a game mode that requires fast clicking and game rush (things I hate most) so I never tried it again.
In Factorio I enjoy the game because in a normal game there no rush, and the game is mostly about right designs and planning, not about fast clicking, while this scenario do controversial things, from my point of view.

From 0.17 release I await mostly map generator update/fix and new pipe mechanics. All other features are secondary and can be released later.
List of other features from most important to least is (as I remember and await them):
- Improving engine performance sounds nice but that's mostly theoretical for me, since I still at 60 FPS on any of my maps.
- More high res graphics is also cool.
- Improved interface - we can wait for it some more years.

[AlexAegis]

If you have to re render the icons at a higher resolution, do it in way higher resolutions too. 128*128, 256*256. 4K is mainstream nowadays.

[winkbrace]

There are lots of games that I enjoy plaing wave defense with. But I love factorio for everything else and I don't think wave defense is a particular good fit with the general idea of the game. For me, at least.

[Engimage]

0.17 looks lika a crap ton of work. Good job guys!
But I personally am looking forward map generation the most - all the bells and whistles are only the shell of a core mechanics (and mapgen certainly is).
So I am looking at you TOGoS

[fessoric]

The "Reset to Defaults" button is red. When you hover over it, the highlighting for the options that will be reset should also be red, not orange. When possible, you should expand the highlight box to cover the label too, and not just the control. On more complex controls, like the sliders, the reset hover should mark a ghost where the slider will move to if you hit the button (for any preset, not just "reset to defaults").

In the progression of good user interface, the steps are Surprise! -> learnable -> findable -> apparent.

Dim orange highlighting of the controls themselves makes the outcome of the reset function "findable" in that a person can carefully scan the list to find them. A huge improvement over the previous version to be sure, and since 99% of everything is on either the Surprise! model or the "check the manual" model, you are already leaps ahead of most designers, and we love you for it. Please take this opportunity to go the extra step - make the proposed changes that will happen when you hit the button "apparent" so that each one leaps out at the user with just a glance and it is virtually impossible for him to avoid noticing them.