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
This comment has been removed by a blog administrator.
ReplyDelete