Category: games

The White Box Essays (Book Review)

The White Box, and its accompanying book, “The White Box Essays” are a FANTASTIC resource, and I wish I’d had them available to me as I designed Elevation of Privilege and helped with Control-Alt-Hack.

The book is for people who want to make games, and it does a lovely job of teaching you how, including things like the relationship between story and mechanics, the role of luck, how the physical elements teach the players, and the tradeoffs that you as a designer make as you design, prototype, test, refine and then get your game to market. In the go-to-market side, there are chapters on self-publishing, crowdfunding, what needs to be on a box.

The Essays don’t tell you how to create a specific game, they show you how to think about the choices you can make, and their impact on the game. For example:

Consider these three examples of ways randomness might be used (or not) in a design:

  • Skill without randomness (e.g., chess). With no random elements, skill is critical. The more skilled a player is, the greater their odds to win. The most skilled player will beat a new player close to 100% of the time.
  • Both skill and randomness (e.g., poker). Poker has many random elements, but a skilled player is better at choosing how to deal with those random elements than an unskilled one. The best poker player can play with new players and win most of the time, but the new players are almost certain to win a few big hands. (This is why there is a larger World Series of Poker than World Chess Championship — new players feel like they have a chance against the pros at poker. Since more players feel they have a shot at winning, more of them play, and the game is more popular.)
  • Randomness without skill (e.g., coin-flipping). There is no way to apply skill to coin-flipping and even the “best” coin flipper in the world can’t do better than 50/50, even against a new player.

The chapter goes on to talk about how randomness allows players to claim both credit and avoid blame, when players make choices about die rolls and the impact on gameplay, and a host of other tradeoffs.

The writing is solid: it’s as long as it needs to be, and then moves along (like a good game). What do you need to do, and why? How do you structure your work? If you’ve ever thought about designing a game, you should buy this book. But more than the book, there’s a boxed set, with meeples, tokens, cubes, and disks for you to use as you prototype. (And in the book is a discussion of how to use them, and the impact of your choices on production costs.)

I cannot say enough good things about this. After I did my first game design work, I went and looked for a collection of knowledge like this, and it didn’t exist. I’m glad it now does.

Image from Atlas Games.

Pivots and Payloads

SANS has announced a new boardgame, “Pivots and Payloads,” that “takes you through pen test methodology, tactics, and tools with many possible setbacks that defenders can utilize to hinder forward progress for a pen tester or attacker. The game helps you learn while you play. It’s also a great way to showcase to others what pen testers do and how they do it.”

If you register for their webinar, which is on Wednesday the 19th, they’ll send you some posters versions that convert to boardgames.

If you’re interested in serious games for security, I maintain a list at

Cyber Grand Shellphish

There’s a very interesting paper on the Cyber Grand Challenge by team Shellphish. Lots of details about the grand challenge itself, how they designed their software, how they approached the scoring algorithm, and what happened in the room.

There’s lots of good details, but perhaps my favorite is:

How would a team that did *nothing* do? That is, if a team connected and then ceased to play, would they fare better or worse than the other players? We ran a similar analysis to the “Never patch” strategy previously (i.e., we counted a CS as exploited for all rounds after its first exploitation against any teams), but this time removed any POV-provided points. In the CFE, this “Team NOP” would have scored 255,678 points, barely *beating* Shellphish and placing 3rd in the CGC.

The reason I like this is that scoring systems are hard. Really, really hard. I know that DARPA spent substantial time and energy on the scoring system, and this outcome happened anyway. We should not judge either DARPA or the contest on that basis, because it was hard to see that that would happen ahead of time: it’s a coincidence of the scores teams actually achieved.

Passwords 2016


I’m excited to see the call for papers for Passwords 2016.

There are a few exciting elements.

  1. First, passwords are in a category of problems that someone recently called “garbage problems.” They’re smelly, messy, and no one really wants to get their hands dirty on them.
  2. Second, they’re important. Despite their very well-known disadvantages, and failure to match any useful security model, and despite l Gates saying that we’d be done with them within the decade, they have advantages, and have been hard to displace.
  3. Third, they suffer from a common belief that everything to be said has been said.
  4. Fourth, the conference has a variety of submission types, including academic papers and hacker talks. This is important because there are many security research communities, doing related work, and not talking. Maybe the folks at passwords can add an anonymous track, for spooks and criminals willing to speak on their previously undocumented practices via skype or SnowBot? (Ideally, via the SnowBot, as PoC.)

Studying the real problems which plague us is a discipline that medicine and public health have developed. Their professions have space for everyone to talk about the real problems that they face, and there’s a clear focus on “have we really addressed this plague?”

While it’s fun, and valuable, to go down the memory corruption, crypto math, and other popular topics at security conferences, it’s nicer to see people trying to focus on a real cyber problem that hits every time we look at a system design.

Image: Mary E. Chollet, via Karen Kapsanis.

A Very Late Book Review

I have to start off by apologizing for how very late this review is, an embarrassing long time ago, the kind folks at No Starch Press very kindly gave me a copy of “Super Scratch Programming Adventure” to review. Scratch for those that aren’t familiar is a kids oriented programming language designed by Mitchel Resnick of the MIT Media Lab, the same team that developed the programmable bricks for Lego Mindstorms.

The book is in manga format and very entertaining and I enjoyed it thoroughly. It was so much fun, that when my then ten year old asked to learn how to program with the long term goal of writing his own minecraft mods, I handed him the book and asked him what he thought. To say he whipped through the book is an understatement. He actually finished it in one reading and immediately asked if he could start playing with Scratch on the family laptop.

Over the next few days he worked his way through some of the programs in the book and put the book aside for a long while. Recently we were talking about an upcoming Lego robotics class he had coming up and he remembered that he had the copy of “Super Scratch Programming Adventure” in his room. He dug it out and this time he worked his way through all the programs quite quickly.

I asked him what he thought of the book and said it was very good; that he really liked the comic book format and that he wished more books were done that way. At this point he’s excited enough that we’ll either dig deeper into Scratch together or we’ll switch to a games oriented text like No Starch’s “Realm of Racket” or possibly Sweigarts’s “Invent Your Own Computer Games with Python”.

Regardless of what we decide to do however, I can highly recommend ““Super Scratch Programming Adventure” as a great introduction to programming for kids or even non-kids who want a first very friendly exposure to programming. And again, my apologies to the folks at No Starch Press for taking so long on this review.