# Open Source Monopoly Heatmap

## A Visualization of the Value of Properties using Java and MATLAB

Whether you love or hate it, Monopoly has cemented itself as a classic tabletop board game and iconic household staple. Its immense popularity throughout the years has garnered dissenting opinions in regards to how the game would best be won. My motivation behind this project is to contribute to this discussion and add to the existing wealth of knowledge.

This project generates heatmaps of properties visited. The data is obtained from simulations with the number of players, turns, and games provided as input parameters. I hope that this can become a useful resource to the community and help to further develop the metagame. You can find the GitHub repository for this project here.

# Background and Assumptions

Monopoly is a 2 to 6 player board game where players with an initial game currency move around the edge of an 11x11 gameboard to collect properties and avoid bankruptcy. For brevity, I’ve linked a PDF of the rules from Hasbro, rather than explaining them here.

In this section, I also want to highlight some of the necessary background information and clarify five assumptions I made in this project.

1 There are 3 Chance cards that move players to Railroad spaces. Of these cards, 2 have instructions labeled as **ADVANCE TO THE NEXT RAILROAD** and **ADVANCE TO THE NEAREST RAILROAD**. In my interpretation, “NEXT” Railroad implies that a player token must move forward. “NEAREST” Railroad implies that a player token can move backwards to the Railroad the fewest spaces away. This has been a topic of controversy on several forums, but I want to be transparent about the results presented in the rest of this article. For hardcore enthusiasts, the code can be modified relatively easily to incorporate a different interpretation.

2 The **MONEY GRAB** Chance card has been removed because it’s garbage. This reduces the total number of Chance cards from 16 to 15.

3 There are 3 other ways to land in the Jail space apart from “Just Visiting”. A player can roll doubles three times consecutively, receive a Chance or Community Chest card that sends them to Jail, or land on the Go to Jail space. Coincidentally, there are also 3 ways to leave Jail. These methods include paying a $50 fine, using a “Get out of Jail Free” card, or spending 3 turns trying to roll doubles. For simplicity, this simulation assumes that players leave Jail on their first available turn. This means that they never wait to roll doubles for 3 turns.

4 This simulation does not consider player balance. Therefore, players are never bankrupted and eliminated from the game.

5 Chance and Community Chest card are shuffled, but “Get out of Jail Free” cards are never removed from the deck and awarded to players. This is implemented for simplicity because player balances are not tracked from assumption #3. There would need to be significant (but potentially worthwhile) revision to the code to check if a player could leave Jail on their first turn from a “Get out of Jail Free” card or by paying the fine.

# Running the Code

This project uses both Java and MATLAB. After downloading from GitHub, start by running MonopolyDriver.java, which will generate all the necessary CSV files for MATLAB to process and plot. The number of players, turns, and games can be edited directly in lines 10–12 of this script. After the relevant CSV files are generated, the MATLAB script will generate and save figures as PNG files in the directory.

In the following sections, I’ll be providing an overview of the different Java classes developed for this project, as well as a brief summary of the contents of each CSV. The intention of these sections is to provide insight into how the code was developed but is not necessary for understanding the takeaways at the end of this article. For those more interested in reading about the findings and applications, feel free to skip to the Takeaways and Discussion section.

# Gameboard Java Class

The Gameboard class keeps track of the properties using a HashMap, where keys are the property indices and values are the number of visits. Property indices are numbered 0 to 39 clockwise around the board starting from GO.

The Gameboard class also contains the Chance and Community Chest card decks. These decks are implemented as lists of integers and have methods to shuffle the top card and place it at the bottom of the deck. Each deck can be divided into “action” and “stationary” cards. Action cards are defined as cards that move the player token to another square, whereas stationary cards do not. 10 out of 15 Chance cards and 2 out of 18 Community Chest cards are action cards. In the list representation of the card deck, stationary cards are represented by -1 and action cards are indexed starting from 0. Indices and their corresponding meaning for both Chance and Community Cards are shown in the Figures 3 and 4 below.

Finally, the Gameboard class also has private variables that keep track of the number of visits to the Jail space by method (i.e. from rolling doubles, drawing Chance or Community Chest cards, or landing on the Go to Jail space).

# Player Java Class

The Player class keeps track of the index of the Player’s current space. The method move(Gameboard g) changes the Player’s space and updates the gameboard through one of three ways: (1) updating the number of visits to a property, (2) shuffling Chance/Community Chest cards, or (3) updating the frequency of visiting Jail by method. Players only record the final space that they land on. Therefore, a Player landing on property index 30 (or the Go to Jail space) does not actually increment the number of visits for property 30 in the Gameboard object, but actually increments space 10 (the Jail space). Similarly, a Player drawing an action Chance card does not increment the Chance space, but rather increments the destination space.

# CSV Files Generated

sampleGame.csv is a table where rows refer to property indices and columns refer to turn number. Each cell refers to the total number of visits up to that turn for the property of that row. The data in sampleGame is populated by the average of all games played in the simulation.

allGames.csv is a table where rows refer to property indices and columns refer to game number. Each cell refers to the total number of visits in that game for the property of that row. The last two columns are reserved for the sum of that row, and the average of that row respectively.

heatmapSum.csv processes the data from allGames.csv and stores it in a 11x11 matrix, the borders of which represent the spaces on a Monopoly gameboard. The total number of visits to each property, stored in the second to last column of allGames.csv, is placed into its relevant cell in the matrix.

Similarly to heatmapSum, heatmapAvg.csv stores the last column of allGames.csv containing the average visits per property in an 11x11 matrix.

propertyStats.csv is a table where rows refer to turn numbers and columns refer to property colors. propertyStats uses the output of sampleGame.csv to sum the total number of visits to properties of a certain color by turn.

# Takeaways and Discussion

Trends may start to appear after high turn counts. At 500 turns per game over 1000 games (Figure 11), “warm color” (orange, red, and yellow) properties tend to receive more visits than any other property. But, it’s not uncommon for there to be variation for lower turn count games. For 100 turns per game over 1000 games (Figure 12), there can be disparity between the results.

Regardless of turn count, Utilities, Brown, and Dark Blue properties consistently underperform. By contrast, Railroads have the highest long term payoff by a wide margin.

Figure 13 shows heatmaps generated from 4 players, 100 turns, 500 games. These heatmaps show that Jail is by far the most visited space. Tokens classified as Just Visiting are shown in cell (11,1). The remaining instances of going to Jail are stored in cell (10,2) and are easily the brightest spot on the map.

Figure 13 also shows that Chance cards are much more likely to send a player to a different spot than keep the player stationary. This is expected, since 10 out of 15 Chance cards are action cards.

# Comparison to Existing Research

One popular heatmap floating around the internet is one created by former world champion Bjørn Halvard Knappskog. I compared this heatmap to the ones generated from my simulation. The Knappskog heatmap analyzed 9450 rolls across 330 games. For my simulation, I decided to use a 5-player game for cleaner calculations. I also employed a basic assumption that 1 turn equates to 5 rolls (1 roll per player, discounting chances for doubles). The number of turns used for simulation is then calculated by dividing 5 from 9450 to get 1890 turns. Like Knappskog, I simulated across 330 games and calculated the average number of visits per game square. Both the Knappskog heatmap and my heatmap are shown side by side in Figure 14.

For the most part, the numbers between both maps are similar. One distinction is that my simulation only records the destination square of the Player (read the Player Java Class section for more details regarding this). It’s not immediately clear how spaces are counted in the Knappskog heatmap. For action spaces that send the player to another space on the gameboard, both the initial and final spaces may be counted in Knappskog’s version. The way that the data is obtained in the original heatmap is also unclear. Throughout my research, I could not find a scholarly article that sourced where the data originated from. It is unknown whether the original heatmap was populated from a computer simulation, or if it was physically recorded from actual games being played.

# Recommendation for Further Reading

There are a few sources I came across while conducting background research that I thought were worth sharing. First, a 2009 research paper titled *Estimating the Probability that the Game of Monopoly Never Ends *by Friedman et al. is a notable mention. This paper estimates that roughly 40% of games never make it past 100 turns. Past 500 turns, the number of games remaining is less than 20%. This is one of the influences for why I only chose 100 and 500 turn games to analyze in the Takeaways and Discussion section. For readers with a mathematical background and access to libraries or databases, this is a worthwhile read as the paper goes in depth into the use of different estimators.

Although only moderately related to the topic of this article, *Negotiation Strategy of Agents in the MONOPOLY Game* by Yasumura, Oguchi, and Nitta in 2001 is a great resource for a better understanding of the game. This paper introduces a case-by-case Card Evaluation function for assessing the value of properties. Although the likelihood of landing on a space is not taken into consideration, this article gives a great holistic view of modelling the decision making process. I think it’s worth investigating if the probability distribution of landing on certain spaces has a place in the Evaluation Function proposed in this paper.

Finally, I found a project similar to mine here. I don’t have a linear algebra background, but I thought it was interesting how a Markov matrix could be applied.

# Conclusion

To begin, I would like to introduce some recommendations for anyone who might be interested in continuing this project. Because I don’t have a statistics or mathematical background, I wasn’t sure if using one player to move around the board was better than using multiple players to move per turn. I also didn’t know how many trials to conduct to come to a statistically sound conclusion. Finally, I’m sure that there are some sources of bias that could be limited. For example, I’ve been told that using Math.random() to control dice rolls might carry some bias with it.

I want to give a huge shoutout to my sister for helping me with the design and implementation of the Java classes for this project. She’s an AP Computer Science student in high school, and while we both agree that no parts of this project were immensely difficult, it was still worthwhile to pursue to get more exposure to class design and application of data structures. If you discover any bugs in the code, it was most likely her fault (kidding)! In all seriousness, I constantly find myself enjoying computer science more as I combine this skill with my other hobbies. For those struggling to find the motivation to start a new project, I’d recommend taking a step back and trying to find an intersection between two seemingly unrelated interests. As always, thanks for reading!