Data Driven Board Game Design

When designing a board game, it takes a lot of finetuning to get the balance right and make the game fun to play. This finetuning in turn requires you to play endless iterations of the game, or does it?

The AI Use Case Game

A while back my colleague Walter called me up, saying he was looking for an expert in board games to help him out design our own game. While I do like to play a board game once in a while I am by no means an expert, but I like to take on a challenge so I decided to see if I could help out.

Walter already had quite a clear idea of what he wanted to make: a board game where you take turns to walk around a monolopy-style track and get to try to complete AI use cases. We discussed for a while, and quickly realised that we would need to start playing to figure out which concepts do or do not work in a board game. So we drew the board on a sheet of paper, used python to simulate dice rolls and took another sheet of paper to keep track of our balances as we did not have any dice nor game money at the ready.

We quickly realised that playing like this wasn't particularly fun. And, if we were to create a well-balanced game we would need to play a lot of games. If only there was a way to automate that...

So, I decided to write a simulation that could play the game for us. But before we dive into the simulation, let's have a look at the end result.

The Game

In the game, you lead a team of data scientists and engineers. Your goal is to create as much business value as possible for your company while you and competitors each finish up to three use cases.

The game is played on a board which looks like this:

Phases of the Game

All players start the game in the ideation field, where the goal is to come up with a use case. While in this phase, you may pick a new use case card every turn, and add it to your backlog. After picking a use case card you may decide to start developing it, in which case you move your pawn to the "start" of the ideation phase. You will have to successfully pass the infrastructure, data & ETL, modelling and productionizing phases in order to complete the use case.

Building a Team

When you are developing a use case, your turn starts with a die roll. Then, you move your pawn forward by the number of eyes on the die, offset by your handicap. Your handicap is your team size minus the desired team size as provided on the use case card: this means that if your team size is too small, you may actually move backward! If your team size is more than three people short, you will never be able to complete a use case.

If you come across one of the yellow line named "team" , then you must take a team card from the stack. These team cards affect your team size, and may provide you with a new team member, may result in you losing a team member, or offer you one or more team members in return for a fee. All players start with two team members, and growing your team during the game is essential!

But a large team also offers a disadvantage: team members are expensive. You will need to pay your team members' salaries at the end of every turn, even during ideation. If you ever run out of money, you will need to take a reorganisation card from the stack. This card will provide you with some extra budget or exempt you from having to pay the salaries for a turn, but may cost you business value or a team member.

Budget

Each use case comes with a budget; you will receive part of the budget when starting the use case, and the remainder once you have passed the green dashed line named "budget" halfway the board.

Action Cards

If you land your pawn on one of the gray fields with an icon, then you must take an action card of the phase you are in. These action card may provide you with a benefit, but they may also give you a disadvantage. This may come in the form of budget, progress (fields on the board), a number of turns to skip, or in extreme cases force you to abandon the use case.

Taking the Use Case into Production

Once you pass the finish line you have completed the use case and may collect the business value associated to it. The next turn you may choose to start ideation and draw a new use case, or start developing a use case that is already in your backlog.

The game ends when a player has finished his third use case; the other players then still get to finish the round. The player who created the most value wins!

The simulation

When you make a simulation for any kind of game, the implementation of the game rules is usually the easy part. Modeling the behaviour of players is much more complicated: they don't follow strict rules when making decisions. And if you do make a set of rules that the players use to make their decisions, then you can have a lot of fun optimising these rules. A few years ago, I did exactly that for the Risk boardgame.

For this new game the optimal strategy wasn't my focus, but it was the game itself. So instead of spending a lot of time on the decisions of the players, I spent more time making sure the game rules were easily configurable. I made some decisions on how players react to certain situations, and I assumed that the game would only become better when people actually put thought into it. That may sound like a dangerous assumption, but since the chance element of the game is fairly heavy I think that the strategy component is not so important.

If you are interested in the implementation, have a look here.

Optimizing the game

Once the simulation was (mostly) finished, we could start optimizing the game. Being a data scientist, I wanted to define a loss function and then let some algorithm find the most optimal game. But it turns out to be difficult to capture the notion of a "fun" game in a loss function . So we went with doing the optimization ourselves, looking at multiple aspects of the game and going with our gut feeling of what is a fun game.

Duration of the Game

Perhaps the most important parameter to optimise was the playing time. No one likes a game that takes half a day or one that is finished in a single turn. So we played around with the number of fields on the board, the number of use cases to complete and the action cards until we were happy with the result.

Of course the expected number of turns varies with the number of players: the more players, the more likely one of the players will be done after a given number of turns. In the end, we settled for about 15 turns per game, which would make the game playable in well under an hour.

Use Cases

Next up were the use cases, in which we needed to balance the desired team size and the resulting value. We wanted the ideal path for a player to be to first develop a simple use case (of which the desired team size is 2 or 3), then a moderately complicated (4-5), and finally a complicated use case (6+). If we wouldn't balance the business value well, it could end up being a better strategy to finish three simple uses cases as quickly as possible.

Above you see the results after balancing: on the left we see that winners have often completed three use cases, but it is also possible to win with only two use cases. That is great: this means players have to balance quickly finishing three use cases versus finishing some with more value.

In the middle plot we see that winners typically finish use cases with a higher desired team size, while on the right we see that these winners typically finished use cases with a sum of desired team size of between 8 and 13. If you manage to finish one use case in each of the three categories you would end up with a sum of 12+, which practically means that you won. That is exactly what we were aiming for!

Budget

Also important are the budgets the use cases provide and the budget that players start with. We want it to be fairly doable to finish the game without taking any reorganisation cards, but it shouldn't be impossible to run out of budget either.

So we had a look at each use case and the expected amount of budget needed to complete it. This, of course, depends on the team size: the larger the team, the faster you move but the more expenses you have. Below are a few examples, ranging from very simple to very complicated. We've plotted the total spent budget while completing the use case for each possible team size.

As you can see, it is very possible to complete each use case as long as your team size is in the right ballpark. If your team is much too small or much too large, your budget may run out.

Finalizing the Design

Of course, the rules and the balance of the game isn't everything that you need. Walter did a great job with the design of the game, which is equally important because no one likes to play a game that is visually unappealing. By now we have several copies of the game, and we've had people play it with us at several occasions. So far the reception has been great... perhaps I should give it a try once, as I haven't played the game myself yet. But my computer has had its fair share with at least a million games.

Want to try the AI Use Case game yourself?

The AI Use Case game is one of the elements of the Data Science for Product Owners training. Next to playing this awesome boardgame, the course will teach you everything you need to know about driving value with data & AI.