I’ve had a couple of people request hints or a solution sheet for How to make a good puzzle, so here it is. If you’re having trouble beating the puzzles, you can check the videos here for hints or the entire solution. Please use it only as a last resort.
The Rubik’s Cube. Sudoku’s. Video games. Puzzles are everywhere, but just how do you make a good puzzle—one that’s fun, and satisfying to solve?
I’ll explain this with levels from Sokoban, a puzzle game where you push boxes to the correct spaces on the grid. I’m demonstrating my points using this game, but they can be applied to most types of puzzles. Since puzzle design is subjective, your mileage may vary, but this is a good starting point that I’m also using for my own puzzle games.
The game I’ve been working on as part as an university project was announced recently, and I’ve been responsible for the UI and UX for it. It falls into multiple genre boxes, including “adventure”, “open world”, “zelda-like”, “farming”, and more. From the get-go, it was clear this project needed a lot of UI, and user friendly one as well. That’s where I come in, and use this post to explain what that process was.
Two years ago, I had an idea for a platforming game. I love the genre, and it wasn’t the first platformer I had made. I had already made a dozen games, from jam games to multi-month projects, but none of them really managed to get a lot of attention. Would my design skills finally be good enough to make a game that would reach an audience, unlike my previous twelve games? Little did I know that it would take more than two years to get the game to release, and even less that the game’s reception would go well over any expectations I had.
I play a lot of indie games, as well as a lot of itch.io stuff – smaller, shorter and simpler games. What I often notice, though, is that some of these games have really tiny but frustrating issues that could’ve been prevented, or moments where I just get stuck thinking the game glitched out.
One tool you could use to help to avoid these frustrating moments is playtesting, which will help you to spot the most obvious issues in your game that could prevent enjoyment. However, playtesting will face you with the ugly faces of your game – especially the first few tests, where you can see all of your game’s shortcomings. It can be depressing, and might make you reluctant to do tests at all. This post urges you to press on, because playtests introduce the element that completes your game: the players.
You will need to move the game out of the bubble it’s being developed in. When you give it to someone else, you will learn new things about your own game. These can be either good or bad, informative or not really helpful. You’ll need to learn to deal with that. Don’t make it the player’s fault (‘You’re playing it wrong!’), instead, look at where it is going wrong on the design level, as objectively as possible. It is human tendency to do this— I find watching playtests embarrassing, personally. It can be scary, but in the end, it’s for the good of the game.
In this post I explain which playtesting progress works for me. I playtest my games from time to time, so having a structure for organizing it is pretty helpful. It was designed to be efficient: get as much useful info from tests while organizing as few of them as possible. I’m intending this post for people who want to get started with playtesting, so if you already have a procedure that works for you, please stick to it!