Friday, February 26, 2010

Puzzle Design and Occam's Razor

Recently in Game Design class we have been developing individual "tutorial" levels in Unreal in order to showcase mechanics we developed previously. And naturally, the route I've chosen to go with my particular mechanic requires me to dive straight into the insane world of puzzle design.

My mechanic is a simple magnetic ball with a magnetic field that can be toggled from positive to negative. The first part of the tutorial level that actually demonstrates the magnet's field is a large, sliding metal block that is, by default, blocking the player's path. The player must discover how the magnet interacts with this object and then utilize that information to progress.

The first iteration was an utter mess. It was the first time I had ever attempted staging a puzzle for the player to solve, and I had attempted to throw too many minuscule things at them at once. During initial playtests, the players never received the correct information, even though they received a large quantity of clutter.

I realized that my problem with the design was in the fact that I had designed the puzzle in a linear fashion, a habit I had brought over from Scripting class. When writing scripts to solve problems, it is legitimate (and many times necessary) to solve each new problem with a new piece of code. If that code creates new problems, write yet another piece of code to tackle those, and so on! (Incidentally, this is the same approach I use in designing magic tricks!)

With puzzle design, I discovered that this method of creation is impossible. When the player went the wrong way, I would throw in a wall or a distraction to make them go the right way again. When one path doesn't work right, I made another. This is what led to the player's confusion, when there were more things in the puzzle meant to account for the player's actions than there were to actually solve. With magic tricks, this is a beautiful thing - it separates the audience from the solution. But in puzzle design, it's exactly the opposite - bad, bad, bad!

So, I decided to go the opposite route. I challenged myself to make the puzzle as simple and transparent as possible, while still being functional. I ended up taking out about 60% of the level. Anything that didn't explicitly benefit the design fatefully met Occam's razor. Things I'd always thought necessary, after further consideration, were found to be nothing but problematic, and/or had much more elegant solutions. The next playtest was an outstanding improvement.

My other discovery at this time was the complete lack of documentation concerning puzzle design for games. This is alarming, considering that all games, at their core, are puzzles, and good puzzle design is essential to creating a good game. There are certainly masterful puzzle designs in popular games (Braid and Portal stand out to me as recent examples), but my fascination with the process of designing these scenarios is largely unsatisfied.

Solving puzzles requires a certain mindset. Creating puzzles involves seeing through the same mindset, both forward and in reverse, through a haystack of probable failures and dead ends, all the while balancing the tightrope of self-designated design and keeping an intimate record of exactly what is being presented to the player and how they might see each point of the puzzle through their own eyes.

Creating puzzles is insane. I'm going to bed.

No comments:

Post a Comment