Tag: escape goat
Finding the Hook for Escape Goat
One of the great things about living and working in the Emeryville area is the local game development scene. Case in point: this afternoon, at the local coffee shop I ran into none other than the Chris Hecker, developer of Spy Party. We had spoken before briefly after a talk he gave at UC Berkeley, but this was the first chance I got to really chat with him.
Chris is the nicest guy ever, and was gracious enough to give me an hour out of his work day to check out Escape Goat and give me some feedback on it. Laptop only, and I had left my 360 controller at home. Chris happened to have one on him. Preparedness.
I got some great feedback on “initial impression” details such as the tutorial and mouse summon controls. The real value was in Chris’s perspective as an uber indie artist (he might even say perfectionist?) which is a new role among my playtesting group. (To contrast, an actual quote from my friend Ryan: “You’re giving them too much for $3. Get this thing out the door.”)
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.
New Escape Goat Visuals
While none of these tilesets is final, they should give a pretty decent idea of what the game will look like. The jungle level is kind of experimental, and I’m not sure if organic levels really work well with the minimalist/blocky look of the game.
Today was an awesome day for getting stuff done–probably fixed 20 bugs and added several long-needed features.