The latest series of commits to the code repository accomplished four improvements:

1. Code development using Jupyter Notebook as opposed to .py script file format
2. Minimum game mechanics to enable a game of players that buy and rent ad infinitum
3. A global VERBOSE argument that declares explicitly what happens in the game
4. A visualization of players’ cash that updates dynamically at the end of every turn

Interestingly, a quick simulation of this minimum game shows that players never run out of cash as buyers and renters who cannot buy houses and hotels.

My next goal is to build methods that allow players to buy houses and hotels to confirm that it is only when this game feature is enabled that players can go bankrupt.

Human Players

Human players select a strategy to leave jail (pay, roll, or card) by considering the state of the game. If most properties are unowned, then players opt to leave jail quickly to buy properties. In this situation, most players pay (or use a card, if liquidity is an issue).

In contrast, human players choose to roll the die and idle in jail for as long as they can if most of the other players have monopolies. In this circumstance, jail provides a temporary respite from expensive visits to these properties.

The Simulator

Currently, the simulator uses a simple logic to get a player out of jail. A “Get Out of Jail Free” card is played, if available. Otherwise, the player pays the $50 fee as soon as possible. Players who cannot afford the fee roll the die until they can leave jail.

This fixed strategy is not ideal because it is agnostic to the state of the game. Unlike human players, the simulated players do take into account the dangers of moving around the board when they choose how quickly to leave jail.

Simulated players lack a method that allows them to examine the board, considering whether the current layout of monopolies and unowned properties makes it advantageous to leave jail expeditiously. (This method will also be useful for other types of strategizing, like deciding whether or not to purchase a specific property.)

A future improvement to the simulator will involve the creation of such a method, making the decision to get out of jail a rational response to the state of the game.

To represent game elements and rules, I designed the Monopoly simulation around programmatic objects. An object of this type has fields, which describe the object, and methods, which describe what the object can do. Methods often work by updating values in the object’s fields.

For example, a player object has fields that describe its status, like board position. Additionally, it has methods that describe the actions it can perform, like a move method that “moves” the player across the board by updating the field that describes the player’s board position.

As a second example, each of the 40 spaces in the board is represented by a programmatic object with fields that describe it (e.g., price, if it is a property). The simulation represents spaces as elements in an ordered list (e.g., Free Parking is the 20th space) that players traverse throughout the course of the game.

For the sake of simplicity, I designed space objects without methods. Any interaction between a player and a space is executed by a method in the player object. For example, properties do not have a collect method to extract rent from players who land on them. Instead, the player object has a pay method to compensate the property owners.

In sum, the simulation uses programming objects to represent the elements of the game as well as the rules that dictate how these objects can interact with one another. Programming objects afford the simulation an economical and intuitive way to represent the dynamics of Monopoly.

I don’t know who is right (though my money is on me), but I know that the way to find out is to collect data. Ideally, we would have risk-seeking players and risk-averse players compete in thousands of games and see which type of player does better than the other. Unfortunately, a Monopoly game lasts about 1,000 hours (not really, but doesn’t it feel like it sometimes?) so this little experiment would take a very long time to conduct.

Thankfully, computers can give us the next best thing. A computer program could simulate a Monopoly game between risk-seeking and risk-averse players thousands, if not millions, of times and determine which type of player does best. Such a program does not currently exist, but I am in the process of writing one in Python to figure it out. I’m not a software engineer so this program may be beyond my ability, but I’m going to give it a shot.

This blog will document my attempt to build this simulator (the code for which is hosted on GitHub). Part of it will deal with the technical hurdles, but most of it will discuss my thought process as I grapple with how to capture the complex human psychology involved in a game of Monopoly in a few lines of code. So should we seek or avoid risk to be the best Monopoly players? Let’s find out.