Corin Anderson (magellanic) wrote,
Corin Anderson

McGuffin GC post

I discovered this note I'd written three and a half years ago, just after the conclusion of us running the McGuffin Game. Dated July 14, 2005:

It's over. Here's some disconnected thoughts that may help a
future game control.

Secure the starting location well in advance. The start will set
the tone for the game, and will host more activity than any other
location. If you plan to do something interesting at the start
(serve food, hide a puzzle, play out a scene from Macbeth) you
need to secure this early so there's time to build up the rest of
the route around it.

Secure all interesting locations well in advance. Securing a
location is a lot like investing: it doesn't take a lot of work,
but it does take time. If you learn that you can't use your
favorite location X, you need time enough to replan, for a new
location or possibly to change the entire route.

Establish a route and set locations along that route early. Not
everything needs to be set in stone, and some puzzles may fit
better at locations that you haven't yet chosen. But, the route
and the specific locations you choose are something that you can
put to bed early in the dev cycle, and that feels really great.
We settled on the route by February or March but hadn't nailed
down all the locations until May. In addition to peace of mind,
settling on the actual locations means that puzzles can be
developed with real message text in mind. It may be hard for GC
to fairly play test these ("I know this is going to point to
Golden Gate Park so let me look for those words.") but GC isn't
the only play testers and retargetting a puzzle can sometimes be
expensive. It's also important to test the actual puzzles, even
if it's just that the message text changed.

Be prepared to pull locations or puzzles from the plan if
playtesting finds them too hard. We discovered, only too late,
that some of our puzzles took longer than we expected and so we
needed to elide some puzzles later on. This caused a
discontinuity in the game which teams didn't like and which was a
bit tricky to administer. We were fortunate that we had planned
that a few of our puzzles would be "muxes" -- able to skip past
one or more subsequent puzzles -- so that we could elide these
puzzles easily. But we needed to skip past puzzles that weren't
in these positions, which was a bummer. The moral of this story:
test the game in real time, and change the game based on this

I asked for permission to use any location that was at a business
or other establishment that had people nearby. The Audubon site,
the model railroad museum, the Chabot Science and Space center,
the initial location at the park, and the final location (game
control) at Google were all used with permission. Chabot was
enthusiastic about us using the site (sorta fits the mindset of
their audience) and the MRM and Audubon sites were willing to go
along with it. I'm glad I asked for permission, because it meant
I had no worries I would be blocked from the location on game

Not all of our sites were monitored, but only two puzzle boxes
were tampered with (the box at Inspiration Point was removed and
the toolbox at Vaillancourt Fountain lost a few of the tool bin
covers). We monitored sites where we had puzzles we would be
crushed to lose, where there was a lot of foot traffic, or that
was an installation. We chose to use a lock box at Vaillancourt
Fountain because the area is a bit sketchy at dark. The box
worked great - nothing inside was taken, although I was surprised
to find the flaps on the top of the box, that usually let you
keep screws and such in the top of your toolbox, were removed by
the time we recovered it. In a future game I would be tempted to
use more lock boxes, for peace of mind, but it's a bit of
overhead for teams and it looks more suspicious to locals when
there's something padlocked to a fence, rather than in a clear
plastic box with a stick note saying it's for a puzzle hunt.

If using pre-set hints, vet your hints. We set up hint text for
about one third of our puzzles well in advance, and the other two
thirds was written by one person and not checked by others. This
was a mistake, because the hint text was misleading sometimes and
wrong at least twice. We recovered, but teams could have been

Train your phone operators. When a team calls in for a hint, try
to figure out what sort of hint they want, and then _give it to
them_. Some teams want just enough information to become
unstuck, and no more. Others, though, want to dispense with the
current problem and hand, and a bigger and clear hint is what
they want. Don't hold back. Especially for teams that are more
than a few hours back from the leader, you want them to (a) have
fun and (b) stay in the game. A 6+ hour spread by 12 hours into
the game is going to be a world of hurt for everyone.

When possible, assign a team/puzzle combination to the same
operator if they call back. The operator will have state from
the team, and the team will feel better that they don't need to
reexplain everything every time. That's not fun.

With our push hint phone sytem we easily handled the bulk of our
calls with two phone lines and two operators. At least half the
time the line was idle, and most of the rest of the time the
second line was idle. Calls came in clumps, when all the teams
were working on the same hard puzzles. When they were on the
easier puzzles, the line was silent. I couldn't imagine running
a game without a push phone system. The savings in operator time
was well worth it. But, note that many teams chose to not talk
to the operator thinking that it was somehow cheating or not the
right thing to do. If we had made it more clear that it was okay
to call for a hint, then we may have needed more bodies at GC.

GC was a 3 minute drive from my apartment and from Doug's
apartment, and most of the manufacturing had happened there. So
our base of operation was pretty proximal to where we lived,
where clean clothes were, where the puzzles that we had forgotten
about were, etc. This helped a bunch. Running out for a moment
really was just a moment, not 45 - 60 minutes. Also, GC had
ample parking just a few steps from our control center. Again,
very handy because we had a lot of stuff to drag in and out.

It's hard to build a schedule of the expected times teams will
take to solve puzzles, but you should try. We had min and max
solve times for each puzzle, and we hypothesized two teams that
were 30% slower than min, and 30% faster than max. We also
hypothesized a team that always hit the min time, and we plotted
these teams' trajectory through our game. We used these guesses
to plan when to change the mux puzzles, to keep people clustered
and to ensure they hit some of the time-sensitive puzzles when
they should. But, in this, don't forget to throw in times from
the acutal real-time drive through. They'll be more accurate
than the in-apartment trials.

Put off the first mux for as long as possible. One team told me
afterward that they were bummed that they skipped a puzzle after
seeing only four puzzles -- it meant that they couldn't win. Not
everyone's this competitive, but he had a good point. Our early
muxes were because we had a time window for the restaurant in the
evening, but, in hindsight, we should have found a different way
to ensure teams would make that window (eg, by having fewer
puzzles and having a tighter spread by mid-evening).


No team tried to game our hint system. With hindsight, I believe
that worrying that teams would try to squeeze hints out of us
that they didn't deserve was an unfounded worry. In fact, often
it was us who would call teams and ask them if they needed a
hint. Teams trying to advance their position by asking for hints
was not something we should worry about in future games.
Tags: puzzling
  • Post a new comment


    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment