Tuesday, May 05, 2009

Recovered Notes on Puzzle Flaws

Whilst away at BANG 21, my wife decided to clean the office and figured a stack of papers that had been untouched for many moons was ripe for recycling. When I got home I found a chunk of my old notes set to be set out for the city to take away. I did finally go through them and recycle about half. One thing I found in the half I'm keeping was an attempt at a list of what I was thinking of as the "Seven Deadly Sins of Puzzle Creation". In reality, though, they're just a list of some of the irritating things I've come across in my scant three years of solving these encoded data reduction puzzles (as I believe one person referred to them). Anyway, I though I'd write them down here so I can recycle the paper.

  • Ambiguous Flavor Text
    Flavor text always seem to be tricky: Don't include any and there's no way to get any traction with a puzzle; include some and you run the risk of people taking every little word the wrong way. I think BANG 22 caused this latter problem more than once, unfortunately. A story was trying to be told about a trapped time-traveler while at the same time giving information about the puzzle. In hindsight (and with enough time), they should have been kept separate.

  • Extensive Data Collection
    I'm not talking about writing down a list of the fifteen people who graduated with honors from the Silly Walk Academy. I'm thinking of having to search a football stadium to find 93 post-its (and using the seat number as a player number, indexing into the player name by row, etc.). There's a certain point where exploring your environment becomes a chore instead of challenging and fun. Where that point is seems hard to define: I've been on an hour-long collection that kept me entertained the whole time, as well as being on a fifteen minute one that I was bored and frustrated after five minutes.

  • Brute Force Puzzles
    These are kind of rare in my experience, but I have seen puzzles written where the *only* way to solve it is to brute force the possibilities. No fun, unless you count writing the program to do it for you as enjoyable.

  • Gibberish Solves
    Usually gibberish is a good indicator that whatever your idea was, it isn't working. But there are puzzles that have solved to seemingly random text and then expect you to find out how to translate that string into the solution. Bad form.

  • Single Word Extractions That Aren't the Solution
    Kind of a minor gripe, especially since it's very rare to be charged a penalty for a wrong answer. But it still irks me a little when we've gotten a "single word or short phrase" that isn't what the puzzle creators want. This is almost always in recursion-style puzzles, so the next step is usually obvious. But still. Another one we did in BANG 22.

  • Guess The Encoding Method
    Many times it's obvious that once you've gotten so far in a puzzle, the rest of the way out is through a common encoding. Even code methods that are now second nature (first letter acrostics, alphanumeric, etc.) may be obvious. But I've seen puzzles where the only aha is that bolded vs. unbolded vs. capitalized letters in text is a ternary encoding. What fun is that? (Well, in one case it was kind of fun.) There shouldn't be any puzzle where just decoding a message is the goal. Which is one reason why we had the extra bits for the salad puzzle in BANG 22.

    And there, apparently, I ran dry. However, since then I have decided on a seventh. It's kind of minor, but still it exists.

  • Anagramming Is Easier Than the Ordering Method
    In some puzzles, you figure out how to get letters from a block of data and immediately you see that the letters form a word, say AMBROSIA. Type it in and that's the answer. Afterwards, talking with the puzzle creator, you find out they had this amazing method to order the letters by using the birthdate of the author of the book that was ghost written by listed author (hmmmm...). That's a lot of wasted effort that no team (okay, maybe one) is going to go to in order to rearrange the letters. I know of at least one team that this was true for the Chessmen puzzle in BANG 22.

    I'm sure there are tons more out there and many exception to even these. But in general, if I come across a puzzle with one of these flaws, it's probably going to annoy me to some degree. Even with the best puzzle, it'd be like having the perfect martini with a cherry in it: I may end up remembering the flaw more than the quality.

    And now, to the blue bin.

    Labels: , , ,

  • Friday, December 12, 2008

    Thursday Night Adventure Game: AGON 4

    Given, Andrea, and I hit an annoying puzzle last night during our second session with AGON 4: The Lost Sword of Toledo. So far, we've only come up against two real puzzles, the first of which was a cop-out slider; the rest of the game, we've been talking with NPCs and carrying out their errands.

    This annoying second puzzle dealt with a music box that had a hidden portion that could only be opened with an eight letter password. We figured the name of the composer who wrote the music would be our solution. We tracked him down, but his name was only six letters long. At this point, we got stuck for about a half-hour, so I looked up a hint. It said we were supposed to look up the composer's name in the teacher's lesson book, notice that the teacher only taught that song in the sixth class and thus enter the composer's name followed by the number six in Roman numerals: LOZANOVI.

    (I love what the hint writer added: "Yes, this will be the solution." [emphasis theirs])

    There's absolutely no way we would have got that. It reminded me of how nobody could come up with "FSKEY" in the season finale of Treasure Hunters (until one of them had a "vision"). Very unsatisfying.

    At that point, we considered switching to another game, but I convinced my teammates that it'd be good to at least find out who stole the sword. Andrea, though, is really looking forward to putting AGON 4 behind us and starting Dracula - Resurrection.

    Labels: , , ,