Tag: puzzles

Some Thoughts on Puzzle Design

The results are in after last night’s playtest, and Escape Goat Alpha 5 is the new face of drinkability.  OK, what I meant to say was that the testers really understood the puzzles better, enjoyed experimenting, and felt rewarded when they completed them.  This was a big changes from Alpha 4, where testers found several of the puzzles so confusing they resorted to trial-and-error.

So what changed?

I have a new approach to puzzle design.  This post is probably a version of something the masters have already discussed at length, and I’m pretending like I’ve discovered the wheel.  But bear with me, I’m a do-it-yourselfer (to a fault) and maybe there’s some original research in here.  Read on.

This all started with a study project where I spent an afternoon playing various puzzle games on Kongregate and Newgrounds. (I know, this is totally like real work.)  I wanted to see how games dealt with the Unsolvable Puzzle Dilemma–how they let the player know it was time to restart a level after it couldn’t be solved anymore.  After playing about 20 games, I found that each of them falls neatly into one of two categories:

Type 1:

These are the reparable puzzles, where you can undo moves all the way back to the original state of the puzzle.  There is no unsolvable state.  A “restart” of the puzzle only serves as a shortcut.  Examples: Rubik’s Cube, simple mazes, slider puzzles.  Portal 2 is a Type 1 puzzle; even though the environment permanently changes as you progress through a room, it’s never in an unsolvable state.  There’s no need for a restart button in Type 1 puzzles.

Type 2:

These puzzles have consequences for every move.  After you’ve made your moves, you’ve either solved the puzzle or failed it.  A restart is now necessary.  Any game featuring destructible environments, blocks that merge together, switches that can only be used once… these are all Type 2’s.  Some examples are: Sudoku, Lemmings, Adventures of Lolo.

Categorizing games into one of these two camps makes things more straightforward.  Type 1’s are all about experimentation and movement within the puzzle, maybe inching toward completion 5 steps forward and 4 steps back.  Type 2’s are about coming up with a plan, executing the plan, and observing the results.  They are different enough that I bet if you ran a brain scan of people solving either puzzle type, different parts of the brain would light up for each type.

So wouldn’t Braid be a great example of type 1?  I mean, you can rewind time as much as you want.

Not so fast.  Some levels in Braid are Type 1, and some are what I’m going to call:

Type 3:

This is the black magic, the unholy witch’s brew combining both styles.  Parts of the puzzle are reparable, and parts are not.

Remember the levels in Braid with the glowy green objects? Some of them got permanently messed up if you didn’t do things in a certain order.  And yet you could still rewind time… you had a sense of being able to repair parts of the puzzle, yet not the whole thing.  And that’s what made these puzzles some of the hardest: once you knew you could make a permanent mistake that your magic time rewinding couldn’t fix, you were forced to question whether you had messed up the puzzle.

Braid did a good job of conveying the unsolvable state, usually with a green door that was shut, or a key that was destroyed and unusable.  You could look at the door and “get it.” It was time to exit the level and restart fresh.

Back to Escape Goat.  I applied this paradigm to the new levels I made for yesterday’s playtest by making sure each puzzle room fit squarely in either Type 1 or Type 2.  Rooms that had to be restarted made it clear that there was nothing left to do–no toggle switches that would shift things back and forth.  (I even added the Back button as a hotkey to restart the room.  The presence of a hotkey should clue players in that restarting is a way of life for some of these puzzles and is nothing to be ashamed of.)

Am I going to have any Type 3 puzzles?  Probably, but not until the final stages.  I recognize that this takes the most brainpower and shouldn’t be foisted on the player in the first ten minutes of the game.

When I set out to make Escape Goat, I had no idea all the things I would need to learn, least of all this categorization of puzzles.  I would absolutely love to hear back from you experienced puzzle game designers.  I’m probably just scratching the surface here.

 

The Dilemma of Unsolvable State Detection for Puzzles

Last Saturday was the Escape Goat Alpha 4 playtest, and the next big design challenge has shown itself and thrown down the gauntlet.  It’s a hard problem to define, so I’m hoping that writing this will clear it up in my head.  It might also make an interesting story for anyone who wants to see the gruesome behind-the-scenes of game design.

Escape Goat is a puzzle game at heart.  You’re there in a room, pitted against obstacles and mechanisms, trying to reach the goal.  My playtest version of the game had several stages of training, where the player learns the game mechanics, controls, and how the various gadgets operate, before being plunged into a puzzle that takes some problem-solving skills to beat.  The first few puzzles would basically solve themselves in a fun and visual exciting way while teaching you how the game works.  These rooms were fun to build–basically single-button Rube Goldberg machines that make you go WHOA, COOL and that’s about it.  Then come the puzzle rooms.

By their nature, puzzles can enter an unsolvable state if you mess up.  There are blocks that drop and can’t be lifted again, crates that break, switches that stay permanently thrown.  If you do things in the wrong order, you’re cooked and have to retry the room.

The problem is, the game doesn’t know when it’s in that state.  Play testers were poking around in a room for a few minutes trying to solve the puzzle even though it was no longer possible.  This just can’t happen in the release version of the game–the lack of feedback is frustrating and boring.  The player has to get the memo that the room is now unsolvable, and a retry is required.  Detecting and delivering this message is the big challenge I’m facing.

The room in its initial state, when you enter from the top right

 

Let’s look at one room in particular.  This room is the first one where you can actually “lose.”   There aren’t many interactive elements, just the three buttons on the top level.  The green one operates the push block on the left, the blue one lifts the platforms in the middle level, and the red one releases the top (red) platforms.  The proper solution is to hit the buttons from left to right, which transforms the level like this:

Press the green button to shift the lower blocks and create a gap
Press the blue button to lift the blue platforms on the middle level
Press the red button to release the top level platforms and drop the blocks

 

The blue platforms lift to catch the blocks, allowing access to the yellow button on the bottom right, which opens up the passage to the left.  If you hit the red button first, here’s what happens:

Without the blue platforms lifted, the blocks fall too far and barricade the yellow button.

 

The blocks have fallen and are blocking access to the yellow button on the bottom right.  You’re screwed.  You have to restart the level from the pause menu or by leaving the room and re-entering.  But… how can a new player know the puzzle is unsolvable now?  There’s no message.  You’re just left wondering what to do next.

I’ve thought of a few solutions:

  1. Design the puzzles so they can’t enter an unsolvable state.  Well, this would make for a pretty easy game.
  2. Design the puzzles so that something kills the player when they enter an unsolvable state.  This is a better solution than what we have now, but it means inserting a lot of violent gadgets (lightning machines, buzz saws) and having to account for all locations the player could be on the screen.
  3. The game checks to see if it is unsolvable and delivers a message if so.  Checking programmatically is something that would add months to the project, if not years, so that’s out of the question.  But maybe the room could have a bit of hidden data built in to detect for states that would make the room unsolvable.  For example, I could have a hidden block detector checking the area in front of the switch to see if the blocks have fallen there.
I like solution #3 so that’s what I’m going to explore this week.  A related problem is how to notify the player that the room can’t be solved anymore.  Options include:
  1. Kill the player instantly, which would be really jarring.  No good.
  2. Bring up an on-screen text sprite, which is more subtle, but not very thematically interesting.
  3. Have a gadget that activates in the unsolvable state and allows quick restarting of the level, a cool thematic solution but maybe a bit too abstract compared with the on-screen text.
I’ll do some quick tests with options #2 and #3 to see which works better.