How to Create the MONOPOLY GO! Effect

Monopoly Go’s economy design makes social casino accessible. The roll-move-resolve loop is more approachable on a board than on a slots reel, so the game can create a real sense of tension (the board piece will sometimes enter bullet time before landing on a tile). Another achievement is the game’s events, which cut to the core of the design.

Recurring events are a key source of how the game creates “runs” by stringing together level climbing in different, interconnected progression centres. While Monopoly Go certainly wasn’t the first to invent “move around board, trigger events”, it’s undoubtedly popularized it. It’s starting to appear as its own genre, and even morphing into Archero 2 mini-games.

Excel Sheet here.

The events “tickle” the mind by creating cascading effects where multiple reward centres trigger, in some time interconnected ways. The economy is of particular importance in casino games, since the main currency functions as energy – without it, player engagement stops, but make it too plentiful and purchases also stop. With more games implementing these loops, I want to setup a basic model to understand how they work. Games in prototyping should be creating economic models to guide design making. The process of making the model is as valuable as the model itself. Creating time-boxed rough model sketches helps vet key design decisions.

I wanted my model to:

• Simulate the first Player 100 rolls
  • Track Dice Balance, and Net Activity Per Move
• Create two “reward” centres to reward additional dice beyond board rewards
  • Players earn progress toward milestones in each centre
  • Monopoly Go features a two main and reoccuring collection events.
    • Beyond login rewards, sticker collections, board completion, Chance cards (that’s a lot!).
• Regenerate rolls on a schedule.
• Take less than 3 hours to build.

The result is here, and available for download. Eventually, we’ll produce this:

Process

I started with the Archero 2 minigame template, with some small changes, to build the board, and first affirmed the expected dice roll reward per roll was less than one (i.e., the player won’t play for infinity).

Next, I want to spin up the player moves. I created 100 and then generated a random roll, incrementing from the player’s last movement of the board. Next, the resulting tile is wired to the tile reward: these trigger the reward centres. I’ll revisit the multiplier later.

There are two: Otta Treasure Level and “Cash.” Both reward Dice rolls for collecting a certain amount of Treasure or Cash. We create look-up tables for all these values, putting in random number to play with and scale. The point of the timebox is to keep moving; good economy designers don’t get weighed down by certain assumptions, and polish later.

Rewards Look Up

The next part of my build, and the messiest part, is the rewards look-up after each roll. We initialize the player at level 0, and if the player earned Treasure or Dice, we calculate the levels they moved up and give the player the corresponding reward.

The rewards from the reward centres and the rewards from the simple board tile are added to the player’s wallet.

Multipler

Now that we know wallets, we can build out the multiplier function. I assume:

• The player always bets up until the allowed maximum
• The maximum is a ratio between the multiplier and the player’s wallet

We can use this rule set to calculate the player maximum multiplier that they could play, and assume the player uses it. The ratio we set significantly impacts the number of rolls a player needs to play! Here, the player had 50+ rolls, but had to churn through them at a slow pace, and the 100x multiplier significantly bottlenecked pace too.

The next feature is Dice regeneration. First, we create a ruleset that triggers a regen period if the player’s balance reaches one dice. The period refills them to their wallet maximum, and we consider that a “session” (the player only returns once their wallet maximum is regenerated).

We’ll add a bunch of other derivative metrics that the model sets up, too. Since we have regen time, we can apply a “slack” rate or the percentage of missed Dice rolls players fail to expend. For example, if Dice regenerate at 100 per hour, a player could log in 24 times a day, perfectly one hour apart, to maximize the reward. The slack rate discounts this amount and implies the number of sessions a player will have per day.

And since we know a regen event triggers a new session, we give every roll a cohort day. Our model predicts the roll will complete the 100th roll by day 2.08, with an RTP or total return to player of 90% (the amount of dice sourced versus sink).

Result

Our net activity chart is the most interesting; we can see that we triggered some of the early reward centres, and two events were strung together. We also see that consistent waves without the reward centres are boring and predictable. The “Go” effect is about setting up these triggers in interesting ways to connect and cascade.

I wouldn’t use Google Sheets for this project in the long run. We only set up a single-player simulation, but Sheets makes it annoying to deal with randomness beyond this (and don’t get me started on seeds). The goal was to spin up a model of understanding, and honestly, there’s enough here to run Archero 2’s mini-game. In the long-run, I would convert this to a Python or R project, and it’s needed at most level of social casino.

Teams should create these models, even for real-time match pacing or combat, and certainly early in production. Modeling building is an exercise in playtesting the design!