DevLog#002 – Tutorial Design

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.

Example of tutorial stage made of animations and wall of text.

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.

Partially redesigned tutorial, that tries to be more interactive with much less text.

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?

DevLog#001 – First Game Design

I like to play puzzle games and for past few months, I was solving lots of nonograms. It’s a 2D puzzle game, where you uncover a picture, encoded with numbers on a grid.

So I started to think, how would it play in 3D? An early prototype, of which sadly I couldn’t find any screenshots, was just an direct adaptation from 2D to 3D. Hints were the same, just with an extra dimension of playspace. But it had a massive issue of being hard to read. There is no way to display 3D puzzle, all at once with hints visible as adjacent columns, there was just too much information on the screen. I needed a better design.

I figured out, if hints were to be displayed on sides of voxels, it would be easier to understand. But it created another issue. There is very limited space on each face, to display a hint, so standard ones wouldn’t fit. They had to be redesigned.

Thus, a number with upper index was born. Big number on a side would say how many blocks have to stay on that line, and another one in upper index, in how many groups.

This was so much better than just a direct port of the idea into 3D! I was happily coding the game, until I’ve reached another issue. It was way too easy. I was struggling with the concept on why, noticing that symmetric or narrow shapes were impossible to turn into challenging puzzle until I realized that there are to many hints.

Back to the drawing board, another change was required. Something that would figure out minimal number if hints that is required to solve a puzzle, without making it too easy. I’ve tried two approaches.

Brute forcing it, to find an actual minimum, which turned out to be impossible to compute on a home PC in reasonable time. I’ve dropped this idea really fast, as number of combinations to check was way to high.

Starting a puzzle with no hints, then adding them one by one until puzzle can be solved. This was much faster but I still ended up with tons of redundant hints that made it quite easy. So I’ve added another step, which tried to remove each hint, see if puzzle can still be solved and then just repeat that, until no hint could be removed. This gave me a fast and reasonably good solution for the problem. It opened up design space to any shape I would want, while still make it enjoyably challenging.