Tutorial. The sworn enemy of players and developers

If you explore the internet, you'll discover an interesting fact: usually both players hate tutorials, and developers hate making them. Sources: [1], [2], [3]. It's a thankless but necessary thing for mutual understanding. The highest skill is when a game - "show, don't tell" - guides itself, encourages experimentation, and doesn't need those unfortunate fingers or windows. And when they do exist, it's better for them to be well-thought-out. Not like when a hint freezes the game, forcing you to watch as text is leisurely typed one letter at a time. Not like when a hint appears and an accidental touch closes it, never to be seen again. And not like when an interaction hint only appears when approaching in a bent-over position from a certain side. In Automatic Tutorial Maker for Unity we've already thought through most of these nuances. For example, solving the problems above: ⚙️ Choose zoom/fade/slide animation for hint appearance and a duration of 0.5 sec. ⚙️ Set a minimum time for the hint to exist - 1.5 sec. Or add a mandatory confirmation button. ⚙️ Activate the hint asynchronously when approaching the target through Vector3.Distance. And here are two paragraphs from the book "The Art of Game Design: A Book of Lenses". Both explore how developers can better explain things to players. The ability to think like a player. "Where does this location intuitively lead me, and where might I get stuck?" Playtests and adaptation. If explanations become necessary, write accompanying phrases in a notebook. This is the potential tutorial that needs to be beautifully integrated into the game. Either in the words of characters or in the geometry of the scene. Actually, at the core of ATM are these two things: the developer sits down and walks the player's path while showing it. This generates basic hints, and it also allows you to review the game through different eyes one more time. To test and improve the tutorial logic while remaining calm about the technical part.

Feb 27, 2025 - 16:17

Tutorial. The sworn enemy of players and developers

If you explore the internet, you'll discover an interesting fact: usually both players hate tutorials, and developers hate making them. Sources: [1], [2], [3].

It's a thankless but necessary thing for mutual understanding. The highest skill is when a game - "show, don't tell" - guides itself, encourages experimentation, and doesn't need those unfortunate fingers or windows. And when they do exist, it's better for them to be well-thought-out.

Not like when a hint freezes the game, forcing you to watch as text is leisurely typed one letter at a time. Not like when a hint appears and an accidental touch closes it, never to be seen again. And not like when an interaction hint only appears when approaching in a bent-over position from a certain side.

In Automatic Tutorial Maker for Unity we've already thought through most of these nuances. For example, solving the problems above:

⚙️ Choose zoom/fade/slide animation for hint appearance and a duration of 0.5 sec.
⚙️ Set a minimum time for the hint to exist - 1.5 sec. Or add a mandatory confirmation button.
⚙️ Activate the hint asynchronously when approaching the target through Vector3.Distance.

And here are two paragraphs from the book "The Art of Game Design: A Book of Lenses". Both explore how developers can better explain things to players.

The ability to think like a player. "Where does this location intuitively lead me, and where might I get stuck?"
Playtests and adaptation. If explanations become necessary, write accompanying phrases in a notebook. This is the potential tutorial that needs to be beautifully integrated into the game. Either in the words of characters or in the geometry of the scene.

Actually, at the core of ATM are these two things: the developer sits down and walks the player's path while showing it. This generates basic hints, and it also allows you to review the game through different eyes one more time. To test and improve the tutorial logic while remaining calm about the technical part.