Tips for Puzzle Game Level Design

[Abel Toy]

Designing interesting levels is hard (at least for me), but what's even harder is designing interesting puzzles - arrange a few elements in an interesting, unobvious way. That's a hell.

So I'm here asking for tips on designing those puzzles. I already know this (thanks, Draknek):

- Playtest, playtest, playtest.
- Create 3 times more levels than you'll need, and decide which ones you'll remove through playtesting.
- Playtest.

Any more tips?

(My intention was to make this post kinda general for a puzzle games, but if specific details are needed to give tips according to this or that, my game is basically Lights Out with a bigger grid [15x15] BUT not every cell of the grid is a playable cells [So empty cells aren't taking into account, allowing irregular shapes]. Moreover, there are different kinds of tiles: the regular +, a x, one which toggles a whole cell, one which toggles a whole row, one which toggles both a whole cell and whole row, an unclickable cell and one which toggles the cells around it but not itself)

[Darien]

Resist the urge to make a super duper giant complicated level that takes a ton of moves to solve. Focus instead on how to make things more challenging without just straight up making them take longer.

[Abel Toy]

Thanks for the tip, Darien! I was already planning to do some small, simple levels which are interesting. I like that. The problem is it's really hard, haha.

People at FGL have also provided some nice tips, here's a sum up:

- Plan each feature as a progression and design levels according to that progression (some say backwards): I already wanted to include that kind of progression, but I was just planning to sort levels at the end. This will make stuff easier :D

- Attempt to do some seed-based procedural generated levels, and grab the interesting ones. This could be hard, but very interesting :D

[Ian Snyder]

Attempt to do some seed-based procedural generated levels, and grab the interesting ones. This could be hard, but very interesting :D

I don't know if I would recommend you spend time working on procedural generation for something like this, but the concept of finding level designs through a process of randomization is sound.

Most levels in my games start from me laying down a few tiles at random and slowly editing and editing and editing until I find something playable. It's a good way to work for me. Laying down tiles at random allows for my hands to be occupied while my subconscious pours over some of the higher concept aspects of the game. It's also a great way to discover new mechanics you wouldn't find by trying to design everything.

One of the big problems with proc gen for this kind of thing is that it will take up a lot of your time finding the right balance between something too random and something too predictable. Your mind is already at the place your algorithm needs to be.

I'd also HIGHLY recommend you make a really good editor for your game, even if only you use it, something that allows you to create and test levels quickly. The less time between idea and creation and test, the better.

[Stephen L (inactive)]

(My intention was to make this post kinda general for a puzzle games, but if specific details are needed to give tips according to this or that, my game is basically Lights Out with a bigger grid [15x15] BUT not every cell of the grid is a playable cells [So empty cells aren't taking into account, allowing irregular shapes]. Moreover, there are different kinds of tiles: the regular +, a x, one which toggles a whole cell, one which toggles a whole row, one which toggles both a whole cell and whole row, an unclickable cell and one which toggles the cells around it but not itself)

Here's an exercise - for each deviation from the lights out ruleset, each extra mechanism, justify to yourself what it adds, and find a couple of sorts of levels that wouldn't be possible in the original game.

Other than that, yeah, just use your noggin. Making levels is super-easy for lights-out style games, but an automated tool to tell you the shortest number of moves that will result in a solution will be helpful for this particular variant. Because you allow the playable area to be adjusted, this will probably be what gives most levels their character, as much as any puzzle content - for that reason I think that puzzle generation won't work too well here (except, maybe, for filling in a predefined area).

As a rule of thumb, lights-out games aren't very complicated because it doesn't matter what order you do things in. If you can introduce something that makes order count, you'll likely find it changing how you approach level design quite a lot, and also changing a lot what the game feels like.

[Jonathan Whiting]

Ian's comments are right on the money as far as I'm concerned. The editing and editing to playable process he describes is how I do ~50% of my level designing. Having an easy editor is pretty vital to this.

Most of the other 50% comes from trying to engineer solutions to put the player in specific interesting scenarios; for example "Can I make it so the right move look like the wrong move". This is hard, but worthwhile. Trying to engineer these things will typically either give you compelling puzzles, or let you know about weaknesses in your mechanics.

I'm not a fan of procedural generation for puzzle levels.

I can't overemphasise the benefit to cutting your teeth on the smallest levels possible. If you can't make micro set-pieces that are interesting then you're unlikely to find bigger levels that are more interesting. You can throw them out later if they feel too small to be worth bothering with in the proper game (I prefer to keep them in though).

Oh, and I guess you might gain something from reading the thread for the (now defunct) level design workshop thing I ran on tigsource a while back http://forums.tigsource.com/index.php?topic=13717.0 . I'd really like to run this again, maybe here, but don't have anywhere near enough time to spare at the moment.

[Abel Toy]

Thanks for your great tips! I see it's better to use handcrafted levels now. Will see how it goes.

And about the level editor, yes, I already had one made just after the engine itself was made, so every level has been done using a cool, visual level editor.

Jonathan Whiting: Dunno what a worshop is, but it sounds good to open one on Level Design here!

[Chris Whitman]

Teach! There's a school of thought that the purpose of puzzle level design is to make the player learn by inventing what appears to them to be a novel solution, so that every level results in them knowing how to do something they didn't know how to do before.

I mean, there're reasons to break away from that. Portal spent half the game doing that and the rest not teaching you anything, and the switch-up worked so well that I was honestly disappointed in Portal 2 for not being able to pull the same trick. But it's a good concept to riff off of anyway.

[FuzzYspo0N]

Our local game dev magazine did a whole series with the creators of cogs, Q.U.B.E, suteF etc, here is a link to all the articles and a conclusion on a whole horde of information regarding puzzle games!

http://devmag.org.za/2011/06/04/how-are ... onclusion/

[Lance Burkett]

Teach! There's a school of thought that the purpose of puzzle level design is to make the player learn by inventing what appears to them to be a novel solution, so that every level results in them knowing how to do something they didn't know how to do before.

I mean, there're reasons to break away from that. Portal spent half the game doing that and the rest not teaching you anything, and the switch-up worked so well that I was honestly disappointed in Portal 2 for not being able to pull the same trick. But it's a good concept to riff off of anyway.

I agree with this idea.

I would recommend that when designing a puzzle, you shouldn't design the space. Figure out how the level is going to operate logically first and then let the spatial setup gradually emerge. Unless the game you are making requires more realism in the way that it is arranged, but even then the focus should be kept logic-based(as to avoid cognitive spiral traps).