Some thoughts on Card Drafting

I decided to get back into board gaming, and ended up getting or playing the following games recently:

Last time I tried a board game was 2012. My girlfriend set up a surprise birthday for me over where we played a new game I had bought on a whim, Lords of Waterdeep (BGG Rank #51).

I am mentioning these games because all of those games happen to use a game mechanic I hadn’t seen when I was a serious board gamer in the 1980’s: card drafting. However, card drafting is a very popular mechanic today. In fact, over one third of the top 100 games on Board Game Geek use it!

The first time I had even seen this mechanic was when I ran across an early euro game known as Web of Power from 2000. Someone corrected me and said that, “there’s quite a number of earlier examples of drawing from a pool of face-up cards than WoP.” Well it was new to me in 2000!

Indeed almost 7600 games have been categorized as using the mechanic, and there are some examples in the early 1900’s using it, but nobody has heard of those games. This got me curious as to what are the earliest examples that might have influenced game designers?

Using the top 1000 as the cutoff, it looks like the first game to have this mechanic was El Grande in 1994. The next year, it won the Spiel des Jahres which must be what got people adding it to eurogames. That same year it looks like Wizards of the Coast modified Magic: The Gathering to create their smash hit Pokémon. Soon we find Elfenland, the Spiel des Jahres winner in 1998, Kahuna, a Spiel des Jahres recommended title in 1999. and Union Pacific, a Spiel des Jahres nominee also in 1999. This is followed by the aforementioned Web of Power which shares its birth year with Taj Mahal, Citadels, and  La Città, all four became Spiel des Jahres recommendations. Wow! Thanks, El Grande, and I guess, Pokémon!

Card Drafting, where have you been all these years?

My guess is if Illuminati (1982), a game I played as a kid, were made today, it would have that mechanic in it. But instead it has card drawing and then playing from the hand. In fact, Fog of Love has that same mechanic, and this is not actually card-drafting. And I think this explains is why the card-drafting mechanic is so popular: it adds an element of strategy through public information (you can choose to draft a card instead of drawing by luck). Games have moved into euro mechanics that want more public-facing strategy and less private hand-holding random draws, so we see more and more card-drafting.

Web of Power actually allows a choice/tradeoff: public drafting of a known card or private drawing of a random card. That’s something to keep in mind because I happen to think that balance between random ameritrash and dry eurogame mechanics are needed to make a good game today.

Rethinking rituals for a new workforce

Cross-posted from the Tink Tank.

Yesterday, I came across this article on the economic and political impact of job automation on FiveThirtyEight. Their analysis was done by looking at the percentage of non-“routine” jobs, under the theory that those jobs are most at-risk for automation. It mentioned that these jobs accounted for all job growth in the United States since 2000, with the Bay Area, where I live, occupying two out of the top three metropolitan areas in smallest share of routine jobs, largest job growth, and largest average wage growth.

Let’s focus on the the discussion of “non-routine jobs.” Given that job growth is pretty much only in this sector, it is just another term for what is a clear change in the workforce of America. Consider that in 2002, sociologist Richard Florida referred to “no collar workers in his book, The Rise of the Creative Class—a distinction he drew up between the dress code of creatives from the blue collar and white collar workers of the previous generations. In 2006, business writer Daniel H Pink said that these new jobs were either “high-concept” or “high-touch” requiring right-brained thinking.

Notice the similarity in non-routine work of a no-collar worker that is either high-concept or high-touch doing work that is not-automateable because it requires right-brained, creative thinking. Ignoring the social and political implications, the reality is that this is a different workforce than the generations that preceded it.

And yet, the rituals that surround that work are firmly grounded in the past.

Our grandparents had their blue-collar wages negotiated under collective bargaining. Our parents had their white-collar salaries determined by performance reviews that were later modernized into 360 degree feedback. What do we have in our no-collar jobs?

As an engineering director with thirty direct reports in my final year at a top 10 internet company, I had to do 360-degree annual review. It was the most tedious part of being a manager and one of the most dreaded thing among my people. Doing a good job with it felt like a constant fight against the natural order of what motivated and inspired my engineers.

And yet, the cutting-edge job performance idea is taking that same process and increasing its frequency and adding big data-esque quantitative metrics. They believe that if you take incentives designed for a non-creative work, automate its application to evaluate non-automateable jobs, have them suffer this dread on a routine basis instead of once a year, and apply arbitrary qualitatively evaluations of right-brained, non-routine, high-concept/high-touch work that this will magically inspire these non-collar wearing creatives to perform better, and not the opposite.

That’s some serious wrong-thinking.

Work Life

Cross posted from The Think Tank.

This is a blog about work life.

As a kid in the 80’s, futurologists predicted a coming generational war between baby boomers hitting retirement and my generation (Gen X) and the next (Millenials). This war would be a series of escalating battles fought on the ballot box over the removal of depression-era social contracts such as Social Security.

And yet baby boomers have been hitting the traditional age of retirement for half a decade now and it hasn’t happened yet.

Ignoring the obvious absurdity of a generation of “slackers” and “hipsters” combining forces to wage war against our own parents, the need was nullified because previous generations delayed retirement and work in retirement while our generation redefines success in work to be more than a race for economic rewards.

We went to war, not with each other, but with the traditional meaning of success and failure, of reward and punishment, of life and work.

If we were to extrapolate this to generational theory, it is not in the rightness of each generational archetype1, but in the wrongness of fundamental assumptions we’ve previously all bought in to.

This wrongness is no more evident evident in “work life.”

Continue reading about work life after the jump


San Rafael, California, United States

Apple iPhone 6, Apple iPhone 6 back camera 4.15mm f/2.2

0.001 sec (1/1647) @ f/2.2, iso32 (29 mm)

Learning to curse

I forgot how much I hate the fickleness of writing software!

I finally gave up on Swift (for now). It’s a easy to pick up language because it resembles more a modern scripting language than a compiled one, and frees you up from historical artifacts like Smalltalk, C pointers, and reference counting. Plus you get awesome things like playgrounds:

Sure, it takes a little bit of chucking random “?”’s and “!”’s in your code before you get the hang of optionals, and I’d fear the performance of a basic structure like a b-tree written in Swift, but it interoperates with C and Objective-C so I don’t have to worry.

Or so I thought. Because of strong typing and the lack of built-in overloads, poorly documented character-based1 functions, here is how I inject a a random letter into a string:

let randomletter = "\(String(UnicodeScalar(65 + Int(arc4random_uniform(26)))))"

And then you find it doesn’t always release variables when you use optionals. create some optional simple objects, add them to an array reset everything and see what your NSLog() (e.g. println())) prints in your deinit:

e.g. BNRItem.swift:

import Cocoa
import Foundation

class BNRItem: NSObject, Printable {
    var itemName:String
    init(itemName name:String)
        self.itemName = name
    deinit {
        println("Destroyed \(self)")
    class func randomItem() -> BNRItem
        let randomAdjectiveList = ["Fluffy", "Rusty", "Shiny"]
        let randomNounList = ["Bear", "Spork", "Mac"]

        let adjectiveIndex = Int(arc4random_uniform(UInt32(randomAdjectiveList.count))) //arc4random() overflows Swift int
        let nounIndex = Int(arc4random_uniform(UInt32(randomNounList.count)))

        let randomName = "\(randomAdjectiveList[adjectiveIndex]) \(randomNounList[nounIndex])"
        return BNRItem(itemName: randomName);
   override var description:String {
        return "\(itemName)"

and main.swift:

import Foundation

var items = BNRItem[]()

var backpack:BNRItem? = BNRItem(itemName: "Backpack")
var calculator:BNRItem? = BNRItem(itemName: "Calculator")
backpack = nil
calculator = nil

for item in items {

// Destroy the mutable array object
println("Setting items to nil…")
items = []

creates 4 items, deletes three. Hello, memory leaks!

Then there are issues when you call C functions like CoreGraphics from Swift. My personal favorite is depending on if I restart Xcode before compiling, one of my apps compiles file or throws an error:

SetAppThreadPriority: setpriority failed with error 45


That’s not to say I won’t use it for the future. It’s just too frustrating for me to programming model (Cocoa Touch) in a language that I’m rusty at (Objective-C) in a new IDE (Xcode), translate to a language I don’t know (Swift), and not know if my errors are my own stupidity, or just the compiler is buggy.

Yes, someday Swift, and Swift playgrounds for learning the language, and perhaps even a mix of Swift and Objective-C in a iOS project, but I’m putting the language down for now until I learn Cocoa Touch.

  1. as opposed to string based functions 

Learning to smile

Learning to smile

I’ve been a manager for 2.5 years and I’ve been too long away from programming. There is something just so wonderful about being able to work again in a world where there is a right and a wrong.1

I decided to start to finally2 teach myself iOS development today for: first, because I’ve never done it before and second, because it’s an opportunity to learn a new language and re-learn an old one3 I haven’t done for over a decade.

We’ll see how it goes. I’m not optimistic.

  1. …and getting the feedback to know which is which! 
  2. This does not count. 
  3. If you call writing a median-based BPM counter for Mac OS X, “learning.” I think the jury is still out since Xcode, memory management, and the user-interface are so different now.