How to Make Game Tutorials Better: Immediate Feedback

It's time to return to the topic of making video games easier to understand, and that begins (and sometimes ends) at the tutorial stage. Trying to teach someone the basics of your game is vital and can be difficult to get right, because every game is different. For today's post, I want to focus on the use of immediate feedback and how two very different, yet complicated titles, handled things differently.

More...

Factorio

Immediate vs. Gradual:

Feedback is a cornerstone of learning, and not just in video games. Being able to see the reaction to your action is pivotal towards building a knowledge base of how something works. The longer it takes to see the feedback, the less impact it has on the player's learning.

This is one of the reasons why action games are a lot easier to learn, because everything the player does or experiences has immediate feedback. Conversely, this is why strategy games are some of the hardest titles to learn in the industry, as feedback is often gradual over many minutes before the player sees the response.

To make matters worse, in strategy and puzzle-based titles, the player often has to make something work by using a combination of multiple elements and pieces to create one big solution. Once again, how is the player supposed to know that piece 30 of 50 is not working and stopping the whole process?

Spacechem

Incidentally, this is one of the harder parts of learning programming, and any programmers can attest to the frustration of having to dig through dozens of lines of code to find that one character that is causing the problem.

This is where a common programming tip comes in handy and how it can be applied to learning complicated games.

Starting Small:

As we've said, trying to create one solution out of multiple parts and options makes it very hard to figure out when something is not working, but there is a common practice when building code that has been effective.

Instead of building out a solution (or code) as one massive thing, you build it out in terms of sections; each one coded and tested to work separately before trying to combine them.

Here's an example: Let's say you want to write a program that calculates the tax of an input and prints out the results. Instead of writing everything at one time, you would break that down into three sections of code: The part that takes the input and assigns it to a variable, the part that calculates the tax and then the part that prints the results.

You can test each section by itself to make sure that the code is working, before making the necessary additions that link everything together. In this way, you're making smaller solutions that add up to one big one. If you run into a problem at the section level, it's far easier to troubleshoot it compared to having all three sections at once to look at.

Now I'm sure you're asking, "What does this has to do with game design?" The answer is that we can extrapolate that out and show immediate feedback works on the same principle with the two game examples.

Making a Build:

Immediate feedback works on a step-by-step process, and can be applied to almost any game regardless of its complexity. In action games for instance, designers do this passively with how they introduce mechanics and challenges to the player.

When you play Super Mario Galaxy, the game doesn't ask you to perform a triple wall jump over a pit at the start. Instead, the game shows you how to move, then how to jump, then how to double jump and so on. By the time the player is challenged to do that task, they would have already done every piece of it separately over the course of play.

And to take this further, we can see this kind of immediate feedback in the game Factorio. Factorio is a sandbox game where the player is given all manner of parts and machinery related to automation and asked to build assembly lines and production chains. Instead of giving the player everything at once to build, they give the player access to the basics first.

Infinifactory

When you start out, you're going to learn how production chains work by building very simple ones designed around a closed loop: Meaning that they should perform a task flawlessly.

From there, you build more production chains and automated systems, until you have one very big assembly line, built out of multiple systems.

This way, the player's knowledge base grows as they put things together piece by piece.

More importantly, because of this structure, it allows them to start learning how to expand their concepts with updated options and the expansion of their knowledge of the game.

Going back to the programming example, if there is a problem, you can usually determine it at the system level before combining everything.

A case of where this didn't work would be Kerbal Space Program. The problem with KSP is that you are building a massive project, in this case a rocket, out of numerous interconnected parts. The issue is that since you can't test things at the individual layer; there is no way to get the immediate feedback to see if there is a problem.

When you finally launch your rocket, you have no idea whether or not what you did will work, or if it fails what the problem was. It's a similar issue that we saw when comparing Zachtronic's Spacechem to Infinifactory.  Spacechem proved to be very difficult to learn, as it was technically a programming game where you couldn't see things as individual parts. The reason why Infinifactory worked was because of the use of immediate feedback.

A challenge in Infinifactory worked like this: You have an input, you have a specific output to achieve, and everything in the middle is up to you. The best way to figure out a solution was to build it in steps, just like in Factorio and basic programming. You start figuring out what you want to do in what order, and build the parts of your assembly line around that. Once one part of it works, you move onto the next and so on until the solution is done.

Recently, a great example of seeing this work in a complicated title was Offworld Trading Company. What they did was break down the tutorial into segments starting with the most important tasks that a player would do in a game. Within each tutorial, the game isolated the most important part of playing at that time and asked the player to do it and see the response.

By the end of the tutorials, the player has done every major element of the game and is now ready to combine that all together to actually play the game.

Learn By Doing:

Immediate Feedback should be a basic philosophy when it comes to tutorial design. I've ran into so many strategy and 4X games that try to teach the player with delayed learning; limiting their appeal to only the hardcore fans and preventing them from growing their fan bases.

Crusader Kings 2, originally posted on Kotaku

Another benefit of this kind of learning is that it helps with the design process. Multi-system game design is one of the hardest elements to get right due to the connective-ness of the different genres/mechanics. Being able to put something together piece by piece makes it easier to learn if things are stable before you start building up.

This also goes back to the concept of harmonizing game design and how successful games are those where everything fits together properly. Once one part of your game is not working, that will infer on the rest of your design and hurt the project.

While you can't plan for everything over the course of a game, little steps and thoughts like this can help mitigate any problems or design issues you might run into.

(For posts and podcasts on game design and the industry, check out Game-Wisdom, along with the Youtube channel for daily videos. And my Patreon campaign to help keep Game-Wisdom ad free, while continuing to put out great content.)