Tips on level design for grid-based movement puzzles?

January 12, 2015 1:32 PM

I'm working on designing a puzzle game based on movement and using a grid. The game has similarities to games like Sokoban, Move, Squarescape and Anticlon...

I'm wondering a few things. The first is if anybody has any ideas on how to go about designing puzzles for a game like this.

I did find a few sites that I will be reading tonight, one of which is this sokoban level design page... But any further tips, either as comments or links, would be greatly appreciated.

The second query is any recommendations on similar games. If anybody has any other games they know of that involve moving a piece around a board to reach some sort of goal, I'd love to know about them. Ideally, they'd be PC/Windows or Android (as I don't have an iThing, or Linux or Apple products).

Thanks for any info :)

posted by symbioid to Computers & Internet (5 answers total)

If you are looking for inspiration, the Puzzlescript gallery is full of interesting experiments in the same genre. Puzzlescript itself might be worth looking into too, it's a tool for making these sorts of games in the browser.
posted by a dangerous ruin at 1:49 PM on January 12, 2015 [1 favorite]

The advice on the level design page is pretty broad. Not to give a non-answer, but I think that if you try trial-and-error and the zone methods a few times each, you'll find this question unnecessary. I'd only add that you should have a few testers who aren't overly practiced at solving the puzzles (because you rotate between them.)
posted by michaelh at 2:05 PM on January 12, 2015 [1 favorite]

I've designed levels for those kinds of puzzle games. It's a pretty broad question, and there are lots of ways to approach it, so I don't know if the following will even be useful, but for me, I find I mostly tend to work backwards: First figure out (a path to) the goal, then figure out ways to obfuscate that path to the goal using the puzzle mechanics. The player is then presented with the obfuscated path, and that is their puzzle.
I also tend to work on paper a lot when designing for these kinds of puzzles. Grid paper :) I'll develop my own notation as I go along, eg a symbol for block, a way to show that the block has been moved from A to B, etc. Pencil and eraser because as I try different possibilities, it becomes clear that some need to be restricted or eliminated, because:
What is the gameplay/puzzle philosophy? You need to be rock-solid on your design rules, Eg. Should the puzzles always remain possible to complete no-matter what moves the player has made, or do you allow moves that render the puzzle impossible, forcing a re-start? (And is the re-start automated or does the player have to notice they've failed?) Or do you allow moves that end the chance of getting a full-score but a bare-bones "pass" is always achievable? If the puzzles must always remain possible to complete, think about how to test your designs against that requirement. (Depending on the mechanics, if you don't have computer solving or playtesters to help, it can be really easy to miss a combination that breaks a puzzle.)
posted by anonymisc at 3:39 PM on January 12, 2015 [1 favorite]

Best answer: First figure out (a path to) the goal, then figure out ways to obfuscate that path to the goal using the puzzle mechanics. The player is then presented with the obfuscated path, and that is their puzzle.

In case it's not obvious, once you have an obfuscated path, then you can take that path and treat it as the new "goal" path, then start obfuscating the obfuscated path...

You'll also figure out little sub-systems of the mechanics, creating new mechanics, which you can start throwing together to work off each other.
Eg arranging a set of three Thingies in such-and-such pattern might create an area where the player can travel past them from this direction but not from that direction. So remember that arrangement - it's useful. Another sub-system might block the player unless they have the jewel, another sub-system might be a collection of blocks arranged in a pattern such that the player can travel through it only once.
Then you can take those subsystems as additional building-blocks for making puzzles.

(But really, you probably don't even need to think about all this - it'll probably all just start happening once you've been engrossed for a while making the puzzles.)
posted by anonymisc at 4:01 PM on January 12, 2015 [1 favorite]

Here are my favorite sokobanish games:
http://qrostar.skr.jp/index.cgi?page=hanano&lang=en
http://www.games4brains.de/
My first link contains one which was a FPP.
posted by Obscure Reference at 9:13 AM on January 14, 2015 [1 favorite]