The Rubby Game v0.1

A while back, I picked up a copy of JitterTed’s TDD Game. The game models TDD’s inner loop. You follow the process of figuring out what the code should do, finding a way to test whether it did it, writing the test code, making correct predictions about the compilation and test failures, writing the production code, getting the test passing, and committing the work. It allows you to cut corners for short term advantages at the risk of wasting your efforts in the medium term. This got me thinking; what other programming ideas can we teach with board games?

I immediately started brainstorming ideas for a board game centred around Ruby, Rails, and testing. The ideas flowed quickly. Players (programmers) would have objectives to complete. The objectives are called “stories” and completing them is called “delivering” them. You’re rewarded with victory points, called “story points”.

To deliver stories, you commit code changes. Code changes come in three flavours: frontend, backend and test. Stories require some number of each kind of change. Players earn tokens that represent the different types of code changes, gather them into commits, and assign those to stories. When a story’s requirements are met, they deliver the story and earn the associated points. The first player to earn 20 story points wins the game.

Along the way, players play cards that modify the game. “Decision” cards provide benefits like additional code change tokens or reduced story requirements. “TDD”, “Continuous Integration” and “Pair Programming” are decisions. “Tech Debt” cards provide short term advantages to the player that plays them, but make things more difficult for everyone later on. I made tech debt cards like “Flaky CI” (which adds random chance when delivering stories) and “Use React” (which increases the frontend code change requirements of the next story).

A couple days ago, I tested the initial prototype of the game with some coworkers. The game quickly ground to a halt when everyone gained lots of short term advantages by playing Tech Debt cards, only to become unable to ship any stories due to the mountain of tech debt we’d just created. The solution was to do the hard work of paying it down to unblock our work and get moving again. To quote one playtester, “this is too real.”

While the core loop of the game seemed fun, things were way out of balance. Some cards that blocked other players work were totally useless. Stories weren’t worth enough points, so the game was going to take too long. Gaining code change tokens and committing them was far too hard, while shipping lots of tech debt was extremely easy. Keeping it easy to do shoddy work and difficult to do good work fits the theme, but the balance was too far off. Players were often unable to do anything useful on their turns not because of tech debt but due to bad luck. That’s not fun.

I’ve worked with the playtesters to figure out some ways to address many of the issues. We’re going to change how drawing and managing cards work. We’re going to make taking on new stories a separate activity, rather than having story cards clog up the main deck. We’re making it easier to manage resources and rebalancing the cards that interfere with other people’s work. Finally, we’re going to centralize the cards that affect the whole team so it’s easy to see at a glance what status effects are active.

I prototyped the initial version with physical cards, dice, and tokens. That was a fun exercise, but v0.2 will be created in Tabletop Simulator. Reworking the physical prototype would be too much work. Hopefully with a digital version we can iterate on it more quickly. It also allows us to playtest it with members of the team that aren’t here in town!

In a few weeks, we’ll playtest the next version with the changes I outlined above, alongside new cards that focus on Ruby and Rails-specific ideas and tradeoffs. So far, this has been a really fun experiment and I’ll keep posting about the progress on it! Huge thanks to JitterTed for the inspiration!