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.
🎮 This is reminiscent of King of Thieves: a mobile game where before saving traps in your dungeon, you need to complete them yourself.
👀 And it also somewhat resembles hunting. To capture the player, you need to think like a player, and also spy on them from your developer bushes, again and again.
Automatic Tutorial Maker (ATM) is a tool that not only automates routine tasks but also rethinks the approach to creating tutorial systems. By taking care of the technical implementation (animations, timings, trigger conditions), it frees the developer from "coding for the sake of coding," allowing them to focus on what truly matters — logic that doesn’t frustrate the player. No more spending hours debugging pop-ups or calculating trigger distances for hints. Instead, you can immerse yourself in the player’s role: analyze where they might get stuck, how to guide them without words, and what level metaphors can make the learning process feel natural. ATM transforms tutorial creation into a dialogue with the player: you design the experience, the tool brings it to life, and the resulting mechanics work like an invisible guide — unobtrusive yet reliable. This isn’t just about saving time; it’s an opportunity to turn a mandatory step into a chance to surprise: when the tutorial becomes part of the game rather than an interruption, players don’t rush to skip hints, and developers don’t dread creating them.
Top comments (0)