Vapourware, the award-winning board game
Last weekend I was participating in a board game jam deep in the centre of Toronto. At this event the goal was to design and build a playable prototype of a board game that is interesting and fun to play. Loving board games as much as I do, when I first heard of this event I immediately wanted to go. Four of us from the office decided to form a team and register. Then we had about a week to come up with an idea for a game.
Of course all of us were busy playing video games like Dead Space 2 (which is awesome if violent) that week so we didn't put a terribly large amount of effort from our free time into it. But at some point during the week I came up with an idea: a board game based on creating software and its inherent wackiness boiled down to a few fun game mechanics and funny cards.
Regardless of what the actual final product would end up being, regardless of the theme of the game or the game mechanics, I wanted to approach designing the game from a user experience point of view, because that's just what I like doing (stop judging me). So this is the story of creating a board game iteratively as we weeded out the parts that weren't fun and ended up with a playable, robust and most importantly fun game called Vapourware.
We started with nothing but the theme: software development. We knew that we would find nearly any game within this theme to be fun, since it's what we do for a living, so we had to make sure to keep the game mechanics simple enough that non-techheads would be able to follow along even if they don't necessarily get the theme. Keeping this goal in mind we just started brainstorming ideas regardless of how crazy they were so that we could think about them further.
We had all kinds of ideas, from clients and financiers to milestone-based project schedules and feature creep. It took us a few days to boil the plethora of ideas into a set of core mechanics we thought would be fun to play: a co-operative game in which the players would take on roles (such as senior developer, marketer and manager) to deal with the day-to-day mess of bugs and issues while still trying to create their software before their time and money ran out. This would involve marketers bringing in clients, who would add money to the company, but only if their pet features were implemented (leading to scope creep). At the same time the project might get canceled if enough features aren't implemented by certain milestones. The game would be a race against time and money, to see if the players could write their software's key features without their company going bankrupt.
By this time it was already Saturday and so we had to actually get down to business and work out the details of the game. We planned to have a calendar made up of tiles, which would be slowly revealed as the game progresses. The tiles would contain things like holidays and special visits from famous people (like John Carmack) as well as bad things like all-day meetings and fire alarms. Every week spent on the calendar would mean that the players' salaries would have to be paid, meaning the company's funds are reduced. To get those funds back, players would have to spend their actions on appeasing new clients to bring in more capital. To top it all off, we wanted to have an events deck, similar to Pandemic's, that would make even more bad things happen to specific players instead of to the project in general.
By the size of the above paragraph, I think you can see that what we had envisioned was too complicated. There were too many different things the players had to manage at the same time. We thought that it wouldn't be much fun to play. We did a very simple playtest of it, and it seemed to me that the calendar mechanic made no sense. Generally, employees know about things like all-day meetings and visits from John motherfucking Carmack in advance. These things don't normally just spring up out of nowhere in the business world. So I felt that we should reimagine the calendar and events deck: the calendar would be for scheduled events, like holidays and special visits (and free donut day) while the events deck would be for unexpected things, like coming in to work to find that last night's build was broken.
At the same time, my co-inventors had ideas of their own for conceptual simplicity: why not abstract away clients and budget completely? Clients and budget were our core mechanic for introducing scope creep, but they seemed far too complicated to that end. After some more discussion we decided that we could remove clients and introduce a "client ire" counter that would be increased from event cards. As the game progresses, clients get angry that their software isn't available yet, so they ask for more and more features in the long run. "Client ire" represents this idea: about half of the event cards increase the level of client ire, making new features more likely to be introduced, but without the additional need for having to manage a budget.
This meant that our idea for a marketer role needed to be blown out the door. It fundamentally restructured how we imagined the game would work. But we all agreed that the reduction in complexity would be more fun for players. Our next prototype incorporated this new mechanic. We wrote up a bunch of fun-sounding features, events and bugs and played a quick two-week game. As we were reading each other's cards as they came up, and were working together to achieve our goal, we were actually having fun! Even if no one else liked our game, we did. At that point that was all that mattered.
We found our game to be a bit too easy, so we tweaked the details over a few iterations to make it less certain that we could win. Once we had what we thought was a good balance, we started making the final prototype that other people would play and judge. We ended up making it out of index cards, a couple of ten-sided dice and bullet casings (for progress tokens). We made a box for it and named it "Vapourware". We wrote up its rule sets and made quick-reference cards so that players can easily see what actions are available to them. Pretty sweet, I think, for a cheapass game made over a weekend.
The core idea of the game was still the same: the players take on roles (senior developer, tester, documenter, analyst, team lead and manager) that each have unique skills that help the project get completed. The project itself is a set of features, both major and minor, that have to be developed, tested and documented. Client ire is slowly generated, and can introduce more features. Show-stopping bugs can come up, and the requirements can change. The software-development team has to fight against these obstacles and implement their major features before the final deadline two weeks from now. If they have too many open issues, the manager's manager steps in and cancels the project for overextending itself.
We brought our game to the judgement panel at the end of Sunday. Almost everyone who played our game said that it was fun to play and that the cards were funny and witty. This was especially true for the people whose day job was software engineering, but other people understood it as well. In the end we considered it a huge success.
And so did other people, because we won an award. It wasn't the best board game of the weekend award, but it was an award nonetheless. And so I can proudly say that our award-winning board game Vapourware is the best software-development board game you will play in 2011.