Posted by kovarex on 2018-09-21

The many lessons learned from testing the new tutorial

We have already pointed out, that we are trying to make a new campaign (FFF-245), and part of it is the core beginning, the NPE/tutorial.

The tutorial is one of the very critical parts of the game, as if the first 15 minutes of a game feels shitty, there is big chance that the player will not play any further. I had this experience in many games myself.

So the challenge could be articulated like this: "The current tutorial is okay, but can we make it great?"

The approach in the current tutorial is to feed the player with the basic knowledge of how to control the basics of the game (the first mission and the start of the second mission) in the fastest way possible.

The player is even given descriptive info like this, to diminish the chance of not understanding how the basic entities work.

After few steps in the 2nd level, the player can start exploring his first self-feeding loop (make iron to make more iron).

The message dialog that stops the game and explains the player various things.

Minimization of the amount of things the player can interact with to absolute minimum, so he can't start doing other things before the basics are clear.

The constant interruptions can get really annoying (typically around 22 message dialogs before the player starts to play relatively freely in the 2nd level).

The possibility, that the player will mindlessly follow the step-by step tasks without understanding it, so he can become really lost later on, and the tutorial basically wouldn't help him to understand things.

The tools used to this is mainly:The possible drawbacks:

So the question is: Can we make a tutorial that makes these problems go away?, and alternatively, How big are these problems actually?

The current direction of the new tutorial attempt is to never use the message dialogs, so the player can learn the game more fluently, and to leave way more things to explore, as learning things yourself has a better chance of success than force-feeding generally.

We made a few tests of the new approach with a few people, the main takeaway, is that nothing is for free, and this approach created new drawbacks.

If the player doesn't figure out something basic, it can be very frustrating for him to figure out what is going on when not moving forward for a long time.

frustrating for him to figure out what is going on when not moving forward for a long time. It might be possible, that some things are just not fun to learn by exploration, and it is more comfortable if they are force fed to you. I would compare this to a friend explaining you how to play a game for 5 minutes compared to 2 hours of trial and error.

There are more possible outcomes from this, and we shall see how different tweaks of both strategies work in the testings. It might be interesting if you mentioned your experience with the tutorial in the comment section as well.

Generic usability improvements

Regardless of the final tutorial approach we choose, we made some generic improvements that should help to avoid some of the pitfalls.

People sometimes struggled (in the beginning), to figure out why they can't interact with an object (open/mine/build, connect wires etc.) when it is too far away. We still keep the Beep Boop error sound and the different (yellowish) color, but we added a short flying text explaining the problem.

Webm/Mp4 playback not supported on your device.

Webm/Mp4 playback not supported on your device.

This also includes GUI related stuff like this:

Webm/Mp4 playback not supported on your device. Webm/Mp4 playback not supported on your device.

Webm/Mp4 playback not supported on your device.

Some of these error had description messages, but these were in the bottom-left corner in the console, but we observed, that since it might quite far from the mouse and focus of the player, it can be easily missed. Even if it is not missed, it is not that comfortable to look somewhere "far away" for an error.

When building/hovering an inserter, miner or any entity that inserter/miner can interact with, the corresponding entities are highlighted. This should help to understand the connection, and even for me, it is useful sometimes to see instantly, whether the inserter is one tile off or not when building it.

Performance tweaking

Sometimes, I wondered why is the performance in Factorio is very unstable. The update runs fine (lets say 5ms) most of the time, and from time to time, it takes much longer (16+), so the frame is skipped, so the game feels choppy. For a long time, I expected, that this is caused by some Factorio tasks that can peak once in a while (train path finding), but the weird realisation came, when I played multiplayer, and I noticed, that other people didn't have the problem, so I started to investigate.

I realized this long time ago when doing performance tests. Running any browser with modern (dynamic) page, or and browser related applications (slack for example) take more performance than you think. I could measure non-trivial increases in performance when I closed all these.

Windows - performance options There is a Power options panel in windows (Control Panel → Hardware and Sound → Power options), you can select different power options. It mainly controls things like how long it takes before it goes to sleep, or when are the Hard disks stopped, but it contains more, notably the minimum processor state, which by default (in the default plan, is 5%):

With this settings, I am seeing performance similar to this on my test save

Values are avarage/minimum/maximum in the context of the last 10 seconds.



While the default for high-performance is 100%:

With this, I am getting this result:

You can see, that the average time spent on update is roughly the same, but with the balanced mode, ther are quite big peaks of slowdowns that are happening regularly. You can test this yourself.

The minimum processor state basically allows the system to somehow slow down or turn off some parts of the processor. Factorio works in a way, that it does a lot of work in the update steps (the 5ms time), and then, the update thread has to wait until the time of the next update.

My theory is that when the thread is waiting for the next update, the system thinks that it doesn't need that much CPU power suddenly, so it slows down, but it doesn't switch back to full power fast enough when it is needed again in the next update.

I would be careful with this, as I can imagine that having this option all the time might not be that a good idea, mainly for laptops, but if your game starts to be choppy because of performance, it is worth a try to set this option for the time when you play Factorio at least.

The forums update - part 2

The new forum theme caused quite some debate on the forum and in the office this week, specifically about the limited content width, and the result is that we added a slightly modified theme to scale the forum to the whole screen width. I would like to know your opinion, whether you prefer a limited content width, or prefer the content to fill your whole browser window, there will be a poll to vote in the forum post for this FFF.

As is standard, you can leave us your thoughts and feedback on our forum.