Our first board game prototype

19th March 2015

Today we tested one of our open data board game prototypes for the first time over lunch. Obviously it was a smashing success, there's very little iteration needed and it will be coming to a toy store near you soon.

Not quite.

On the whole, the game didn't really work. But there were lots of ways we could see to make it better.

What went wrong

It was immediately apparent that there was way too much going on.

When building a prototype for the first time there's a giddy desire to throw as many fun board game mechanics at it as possible. This first protoype had way too many bits: dice *and* chance cards, tile building, action points spending, two thinly veiled imitations of the Robber in Settlers of Catan, issue spreading and apps that needed to be completed for the game to be won. There were also a couple of “health gauges” (think the infection rate increasing in Pandemic) that didn't get used at all.

The aim of the game, on paper, is simple: link different types of data together (different coloured hexagons) to build a variety of apps and services. ‘Open' hexagons can be linked to by any player, whereas closed datasets can only be built on by the player that owns that data. The chance cards, the Robbers (quickly named Lawyers), the issues spreading: all these extra bits were placed on top of the idea of linking and opening (data) hexagons.

It was all a bit too much. There were lots of arbitrary rules that had no consequences, and perverse incentives for undertaking certain game actions. Sometimes we were making the rules up as we went along.

Things we learnt 1: the incentives to open up data were the wrong ones

Opening up data in the first prototype cost players nothing and rewarded them with two maintenance dollars - basically "the ODI dream" as James put it. Players could open up their data without hesitation, and get rich quick by doing so - without actually generating any impact.

Open data spread across the board quickly, but there wasn't a lot of complexity. In the real world, the decision to open up data is usually one that involves thinking carefully about how you want people to engage with your data, and the benefits and risks associated with opening up for your own business/organisation. The board game should capture some of that complexity.

On a positive note, we could immediately see how the joining together of hexagons could be both competitive and collaborative. In some circumstances, it might be in the player's interests to open up data and join it together with other players' data, so you can complete apps faster - but you could also 'block' someone from completing their app (joining up all the hexagons) with one of your closed data hexagons.

Things we learnt 2: we need to get rid of all the rules, man!

There were way too many unnecessary rules in the game, that created inefficiencies or just failed to understand the data/hexagon landscape. For example, one chance card instructed players to attach personal data “issues” to every footfall dataset, which would spread to any attached datasets. However, the card didn't mention whether those footfall datasets were closed or open, and as Adam raised: How could a personal data issue spread from one dataset to another if the data is closed?

What will we do next time?