3.4 KiB
| authors | debug | answers | ||||
|---|---|---|---|---|---|---|
|
|
|
Making Excellent Puzzles
We (the dirtbags) use some core principles. If you're writing puzzles for our events, we expect you to bear these in mind.
If you're doing your own event, you might still be interested in these: it's the result of years of doing these events and thinking hard about how to make the best possible experience for participants.
Respect The Player
Start with the assumption that the person playing your puzzle is intelligent, can learn, and can figure out whatever you ask of them. If you observe in trial runs that they can't figure it out, that indicates a problem on your end, not theirs.
Expect Creative Mayhem
This is a hacking contest. People are going to be on the lookout for "ways around" your puzzles. This is something we want them to do: as a defender, they need to be always searching for holes in the defense.
Here are some examples of "ways around". All of these have happened at prior events:
- Logging into your appliance and changing the access password
- Flooding your service off the network
- Brute-force attacking your 2-letter answer
- Photographing your printed list of answers while a team-mate chats with you
- Writing a script to create hundreds of new accounts faster than you can remove them
It's important to remember that they are here precisely to cause mayhem. If you set up a playground where this sort of mayhem ruins the experience for other players, we (the people running the event) can't penalize participants for doing what we've asked them to. Instead, we have to devalue points in your category to the point where nobody wants to bother playing it any more.
Make The Work Easier than Guessing The Answer
An important corrolary to expecting creative mayhem is that people are going to work hard to come up with creative ways to get points without doing the work you ask.
It's okay to make your work about the same level of difficulty as guessing the answer. For instance, we use a few 4-byte answers. It would take about four hours to try submitting every possible answer, and if people want to spend their time coding up a brute-force attack, that is a constructive use of their event time and we're okay with it. Typically people give up on this line of attack when they realize how much time it's going to take (figuring this out is also a productive use of time), but once in a while people will go ahead.
This means your answers need to be resistant to guessing and brute force attacks. True/false questions are, needless to say, going to result in us laughing at you.
There's More Than One Way To Do It
Don't make puzzles that require a specific solution strategy. For instance, we're not going to allow puzzles that require a certain technology (such as "what is the third item in the File menu on product X's interface?").
Rather, if your goal is to highlight a technology,
you should create puzzles that show off how great the product is for this application,
compared to alternatives.
Something like "mount this file system from 1982 and paste the contents of the file named foo"
might be trivial in a certain product and take hours by other means.
That's fine.
That's what we want to see.
The answer for this page is moo