Inventing Puzzles

June 5, 2013 by Terry

Inventing puzzles is one of those things that is seriously difficult and fun at the same time. It’s also satisfying to see a player fiddle with your puzzle for the better part of an hour and get a big smile from finally solving it. After building several of them I really want to make a puzzle game. Maybe I’ll get to that someday. Retrobooster is not primarily a puzzle game, but it contains puzzles so meaty that they are the dominant elements of the levels that contain them. Recently, I decided the puzzles had become substantial enough to warrant adding the “puzzle” genre to the game’s Steam Greenlight page.

trapped_puzzle

This image shows an example of the type of puzzle to expect in Retrobooster. You have to get your ship from one side of the puzzle to the other by shooting the button and navigating the teleporters and force fields. Buttons are used to activate and deactivate force fields and other game elements. Don’t worry, this image doesn’t provide enough information to solve the puzzle. I have intentionally not described the behavior of all the game elements so as to not spoil the experience later. As you may have guessed from the image, I prefer puzzles that are self-contained where all the information needed to solve them is clearly observable. If you were ever frustrated by one of those game puzzles that couldn’t be solved because you neglected to pick up the rope on the other side of the kingdom, there’s a good chance you will agree with this puzzle design philosophy.

The puzzles in Retrobooster are based on:

  • Space (arrangement of puzzle pieces and player’s ship)
  • Time (the order of events triggered by the player)
  • Movement (the way the player shoots and navigates the ship among the puzzle pieces)
  • Emergent properties (unintended game mechanics created by the interaction of game elements)

My favorite puzzle elements are the ones that derive from emergent properties of the game mechanics. These are properties that I have observed after toying with the game a lot and have found a way to use in the puzzles. Using an emergent property almost guarantees the player will have to do some lateral thinking in order to find a solution. I wish I could be more specific in describing the emergent properties in Retrobooster, but that would give hints to some of the puzzles. Games with realistic physics tend to have emergent properties, and Retrobooster is no exception. I think this is simply because all the physical interactions come with spatiotemporal side effects.

When first designing Retrobooster, I made teleporters and three types of force fields with the intention that they could be used to control the flow of levels, make interesting flying scenarios, and be used as puzzle pieces. This all worked out as planned. The big deviation from the original plan was the way the puzzles were designed. I started out sketching them on paper, but it was difficult to think about them this way and they usually did not function as intended once I built them. Only one puzzle from these sketches remains in the game. After the game mechanics were nearly final, I started trying to build puzzles by simply laying down puzzle elements in interesting combinations in the level editor. With a little experimentation I was able to find several puzzles that worked well. As a huge bonus, by playing the puzzles in the game as I built them, I was able to see how emergent properties affected the puzzles and exploit those properties to make better puzzles.

Some have asked if the puzzles will just be a boring chore after you solve them the first time through the game. I have been planning for this potential problem from the start. First, the puzzle pieces are designed to be responsive and fun to interact with. This was necessary–not just because they are puzzle pieces–but because they are also used to control the flow of levels in other ways. Players interact with these pieces frequently throughout the game. Second, most of the puzzles come with interesting flying or shooting challenges built in. Once you solve them in your head, they are still challenging to complete. For these reasons, I think the puzzles will have staying power even after they are solved. However, I can’t be certain without a lot more playtesting.

Another question nobody has asked me yet is how the puzzles behave in co-op games with more than one player. As it turns out, this depends entirely on the puzzle. The puzzles are all designed for one player, and I have not yet figured out how to extend any puzzles for multiple players. In the worst case, a puzzle can be completely circumvented by cooperative manipulation of the puzzle elements. This isn’t all bad since it introduces a new type of cooperative gameplay. In other cases, a group effort will serve to get all but one player through a puzzle. The puzzle must still be solved by the last player in order to complete the level.

There is much buzz these days about procedurally generated levels, and sometimes you even hear about procedural puzzle generation. It has me thinking about puzzle generation compared to puzzle design. It would be interesting to try to implement a puzzle generator for Retrobooster. To a large extent this might be possible, though much more difficult than generating Sudoku boards. The part that I can’t imagine how to do is to exploit emergent properties of the gameplay for this or any other game. Perhaps after you observe such a property, you could program it into your puzzle generator. I suspect a more practical approach would be to do procedurally aided design: let your generator build puzzles, and then tweak them to take advantage of emergent properties.

One thing is certain, it would be astoundingly difficult to do pure procedural generation and have the results feel like they were designed by a person. It’s tough to fake imagination.

The puzzles in Retrobooster have turned out to be genuinely difficult. There are currently thirty-three levels. Seven contain puzzles, and some other levels have elements that are puzzling but not outright puzzles. Judging from the playtesting so far, the puzzles alone will probably take most players between four and eight hours to solve. This isn’t just a shooter; you’ll really need to think to finish this game.

Leave a Reply