For a puzzle game it felt to be good idea, to start working on tutorial as soon as possible. Especially for one where rules aren’t widely known. Even better, is not to develop it in vacuum, and have people who never played the game, or possible don’t even like the genre to try it out. In my case, it did affect game design a lot. Weirdly, it had most impact on the gameplay itself instead of tutorial.
My first approach was probably, the most common one. Also the laziest, I admit. Put few tutorial steps, with text and animations. Try and explain rules, then drop player into game, to a set of easy to solve puzzles. I was thinking, that it would be enough, from a perspective of someone who already got a good grasp on the rules. Turns out that (obviously!) I was completely wrong. First playtest, revealed how big of a disaster it was.
First, I didn’t want an option to skip tutorial. But the way tutorial worked, you could just spam click continue and get to the game before even having a chance to understand it. That is what happened on my first playtest. Another one was that text + animations, well, while might have a chance to explain stuff, is not a good way for teaching. People don’t like to read stuff like this for most of the time. I kind of knew that, but I still hoped it’s not the case. Well, I will believe that in my next game.
In result of this playtest, I went for second most obvious version. Gradually explain mechanics, by disabling most of UI and then introduce it part by part, while user has to solve the puzzle. Each of tutorial puzzles, would be designed around that given mechanic.
This worked a bit better. Friend who I’ve asked to test my tutorial, did engage with it a bit more. But it was still not clear to him, what’s really going on. For some of mechanic concepts, he had different idea of how they worked, resulting in him, randomly removing blocks, until he solve the puzzle and progressed without really understanding why. Also I had a undo-redo mechanic which wasn’t hinted and lacked UI, which resulted in a reset button request. In a stage where I tried to explain how you can slice model to see what’s inside, first reaction would be to drill hole, do whatever is needed inside, and patch it up.
This got me thinking again, as previously, when I talked about my game concept, an idea of introducing lives/chances was brought up multiple times. Initially I discarded it, thinking that it would push the game to far away from nonograms. But, introducing this concept, will most likely, solve issues I’m having.
First tutorial stage currently, can be messed up with clicks and I can’t really explain to use what they are doing wrong. Not without giving players lots of extra text to read or bunch of animations that would someone have to explain what did they do wrong. People giving up right after opening the game would be a really bad turn out. Making blocks that are not supposed to be removed, costing player a life on click instead of getting removed, feels like a really good solution to me.
Introducing changes would also make UX much better. Currently I have 3 painter types: free draw, line and volume. Volume would become obsolete. Same with cube types. You would only need to remove cube and mark it was as staying, never redraw the shape. Which also solves an issue with which cube to select when drawing shapes? One I’m clicking, or one next to it? Currently, if user removes a cube by mistake, he first have to respawn it, then mark as green again. This will also open up some doors, on how to score user performance and maybe some achievements for solving everything without a single mistake?