Jotting Notes on my 'Clues' talk from GC Summit 2007

(with apologies to Larry Hosken)

Some of this information is out of date, but there's still useful stuff in here. And no, I didn't do this merely out of narcissism; I'm writing up a "clue design primer" for general reference (and specific application to a planned upcoming multi-city puzzle event--more on that later), and I needed something to get me started.

• What are your goals for the game?
  • Immersion, theme, cool puzzles, other?
• Weekly GC meetings
  • frequency maintains momentum
  • there's always something you can do (even just talking)
• Starting the clue design process:
• Someone will have an idea
• Bring a prototype to meeting
• Example: "meat clue" from FoBiK called "food cryptogram" in development
  • Original idea was pencil, string, raw hot dog? ("gross food clue")
  • CKL: "There were only two kinds of meat."
    Sean: "Rancid and rotten!"
• Set criteria for including clue in game
  • For FoBiK, every clue had to be scary, creepy, or disgusting
• Packaging is very important
• DeeAnn (logistics maven) isn't really into puzzles
• Use previous clues as models/templates for new clue
  • Steal from clues you liked (cool encoding/construction)
  • Change it up, repackage it
  • Only so many encoding schemes available
  • Take an old idea and put a new twist on it
• First playtest (clue prototype) within GC
  • Saves outside playtesters for more polished versions of clue
• Playtesting parties!
  • More like conference-room puzzle hunts
  • You can draw playtesters from people who wouldn't play in your event
  • Usually go through 3 puzzles in 1 session (4-5 hrs, depending on attendance)
  • What did they like? Was it fun?
  • Worksheet - time data is crucial, helps us estimate average timing & spread
• (DeeAnn should do a talk just about skipping)
• Example: Hogwarts dry run
  • Good for testing integration of everything (clues, locations, etc.)
  • Also forced wand-maker to finish gadgets earlier
  • Showed us several problems we fixed before actual game weekend
• Example: 8-ball was not significantly less work to do than full weekend game
• Argument in JU about whether to do dry run
• Living room playtest != in a van at 3am playtest
• Every team eventually hits "the stupid hours"
• Red: we find it takes any team at least 15 minutes to start working on a clue
  • confirmed; Crissy rode along with several teams on Zelda
• Playtesting is like usability testing
• Documentation? We do our best - Hogwarts wiki
• We like to give our phone force a lot of latitude in giving hints
• We're all about customer service - everyone has fun!
• Red: Team Snood takes detailed notes during playtesting
  • Note times when solvers make each "leap of faith"
  • Help system comes directly from those notes
  • Sean: important to note false starts and red herrings
  • dry run helps to identify additional environmental elements which interact with clues
• Red: in Overnightmare, noted playtest times including false starts
  • actual solve time + false starts = spread
  • not necessarily red herrings
• Sean: "the perfect clue"
  • each predictable false start reveals a "signpost" to steer you back to right track
  • avoids too much feeling lost
• little things can help you sort out extraneous bits of data
• usually you find a dead end when you decode to gibberish
• "Only Game Control thinks that's funny"
• goes along with "not having fun anymore"
  • allows teams to give GC non-bitchy feedback (this isn't working)
• JU Saturday night traffic on bay bridge - another argument in favor of dry runs

~CKL