Prototyping a puzzle game for solvability of levels

Question

I am in the prototyping phase of making a puzzle game for iOS. The basic premise of what the player has to do is get from point A to point B by navigating through a maze like setup, while moving blocks out of the way, and avoiding enemies. This is my first approach to a game like this so I am wondering how others have made sure that the levels they create are solvable.

For example take the classic Unblock game where you have to move the red block off the game board by moving the other non red block pieces out of the way. It gets difficult because they are all in a tight space with not much movement to be had.

Has does the creator know that the arrangement of puzzle pieces are placed in a way that makes it possible to solve the puzzle? Do they start with paper prototypes and work from a solvable end state backwards to make the initial game board layouts?

Answer 1

You seem to be making a Sokoban-style game. You have at least 3 options:

• Working from a solved end state. My gut feeling says this is not the optimal solution, because a) there are usually many end states and b) the puzzle does not only have to be solvable, but also interesting. So you should probably rather pursue one or both of the other 2 options:

• Automatic testing. Unless you are making huge levels, there are actually few actions a player can take, most of which will quickly lead to an unsolvable game state. That makes this perfect for a bot to exhaust all possible moves. If there is at least 1 path that leads to a solution, then the bot will find it.

• My preferred method would be manual testing. So you come up with a general idea for a level and lay out the board, you place obstacles and movable blocks, etc. Then you try to solve it as if you were a player, and you must consciously observe yourself. First of all, of course, is he level solvable? An automated test can help you very much with this, that will save you a lot of time. Second, is the level fun to play, is it interesting enough so that the player wants to solve another? That, apart from mere solvability, is the prime question if you want to make your game good. Next, you have to judge whether the level is easy or difficult, and you probably want to present them in that order: easy to difficult.

TL;DR: Implement a bot that can quickly check whether or not a given level is solvable at all, preferably in your level editor. Then design levels that could be fun to solve. Then manually playtest for the actual fun factor and difficulty.

Answer 2

This was also my question for a long time, I'm not sure If it's the best practice to create puzzles but I've got an answer now. To make the story short just imagine a simple valid end game situation, then move step by step backward and get to an start point.

Now to give more details: you want the puzzle to always be solvable, from gamers point of view it's not important if the puzzle has two or three solutions but to have at least one! Keeping that in mind you can start your design by making reverse valid moves. You said it's a game that you need to somehow move all the blocks off the gameboard. So for the first step imagine playing being at the edge of map, and there is no red blocks anywhere on the board. From that situation you start making reverse moves which are normal moves (reverse of another normal move), or pulling a block (which is reverse of pushing block) and pulling a block into the gameboard (which is obviously reverse for pushing that block out of scene). By this approach you know there is always at least one method to solve the puzzle, you can do undo all those steps you took to create the puzzle for solving it.

As Hackworth suggested creating puzzles this way might generate very simple or non creative puzzles at first, but after making some puzzles you will little by little learn what type of moves will result in a good puzzle. It's exactly the same way a player would gain experience to solve harder puzzles after solving simple ones.

Answer 3

This is a really interesting question. The best answer is that when designing your game mechanics, you should be considering how you want to be building your puzzles. Creating a puzzle that is fun to play is sometimes different from creating a puzzle system within which you can create the proper (large) number of fun puzzles - this is one of the important distinctions between Developer and Player.

But you already have some rules in place, so let's see how quickly we can get you to a good, repeatable puzzle creation method. We need to start with goals. (You can't win without goals!) Here are some possible goals for you:

1. The levels should be aesthetically beautiful.
2. The solution to the levels should be elegant.
3. Each level should have a unique solution.
4. Each level should have a well-defined difficulty (so you can order them properly)
5. Each level should be very different from every other level.
6. You need 1,000 levels.
7. Level creation should be simple enough for users to do it.

Come up with a goal that is right for you, and then work backwards from there. If you want beautiful levels - then you need a system within which you can make any arrangement solvable with limited tweaking - so that aesthetic considerations can dominate. If you need X levels, then you need a process you can automate - or have a big team working for you. ;) You goals should drive your solution.