54. Deconstructing Monopoly GO! Through Progression Vectors
Article and discussion about how you could build a game like Monopoly GO! through basic progression vectors based strategies.
Monopoly GO! is a proper example about how tightly integrated progression systems, economy controls, and monetization can create a live service beast, resulting to remarkable amount of revenue.
Regarding its success, the main question everyone has probably asked themselves at some point is: How can I approach building a game like this? Would it be complex because of the RNG mechanics involved, or are there other strategies?
Monopoly GO!, Coin Master, and Dice Dreams, Revenue (Source: AppMagic). Want to build successful games like this? One way to approach them would be considering strategies I’m discussing in this article. Keep reading!
I can give you a small head start on building a game like this, using some very simple fundamental methods. Specifically, systems design methods — because designing games like this requires scalable, configurable, and live-operatable systems, all viewed through a user experience lens.
Disclaimer: Readers should acknowledge, while I’m introducing a simple progression vectors-based approach here to building a game like this, from a very basic systems design point of view, that there can be various other means and methods to build a game like this. And, once again, the use of this presented approach and insight I’m providing here should be used always with a grain of salt — and it would be always on my readers’ responsibility to carry over all risks and opportunities associated with using the methods I’m presenting in my articles. This article presents a theoretical approach for designing games like these, with no direct association to the games or companies making these games I’m using as references and examples. Thank you for understanding.
Progression Vectors: The Anchors of Game Structure
At its core, this type of a game can theoretically thrive on a small set of interlinked progression vectors — primarily e.g., just by Location progression and Net Worth accumulation — which two can serve as the backbone for everything, including e.g., player progression, core gameplay controls, core gameplay scaling, economy, monetization loops, and live events. Below, I’ll dissect these systems from a basic systems design perspective, including keeping in mind modularity to other genre leaders like Coin Master and Dice Dreams; and offer a strategy on how to scale systems from MVP to a full, high-frequency event live game like Monopoly GO! is.
Location Progression
Definition: The sequential unlocking and upgrading of “Boards” or “Cities” (Locations) that form one of the the primary long-term objectives.
Purpose: Provides a macro layer of progression that anchors the player’s sense of achievement and completion.
Control Point: Each Location_ID in the config files becomes a master key for defining e.g.,:
Required Building upgrades and costs.
Board layout / Tile setup and rewards tied to them.
Tutorial / FTUE / narrative triggers (incl. their beats).
Bot / Player pool compositions for social features.
Dice Roll outcome weighting for Board layout / Tile setup.
IAP offer segmentation / contextualization.
Store offer (incl. Store layout) segmentation / contextualization.
And much more.
Net Worth Progression
Definition: The sum of player assets across all locations; a meta-measure of progress that scales linearly or exponentially depending on economy and progression design.
Purpose: Creates a universal scaling metric that can tie into e.g.,:
Core gameplay feature unlocks (e.g., automated Dice, Dice multipliers)
Tile income (/penalty) increases.
Reward scaling for both core loop and events.
And, again, much more.
Building the Economy: Sinks & Sources Around the Strategy
The heartbeat of the game and its curves can reflect e.g., two primary economic control philosophies:
Option 1: Exponential Sinks, Linear/Smooth Sources
Sinks: Costs for upgrades, events, and progression rise exponentially.
Sources: Dice Rolls, income, and rewards grow at a slower, smoother rate.
Effect: Creates a permanent “chasing” dynamic where players are always behind, driving monetization pressure (mainly through Dice Rolls).
Option 2: Mixed Scaling
Both sinks and sources scale with a mix of exponential and linear growth, but sources lag e.g., 1–2 progression steps behind.
Creates catch-up bursts but still maintains the long-term gap that fuels monetization.
Monetization Implication: In both approaches, Dice Rolls remain both the core heartbeat as well as the bottleneck resource — granting the ability to earn, progress, and participate in Events as well, as they are introduced — making them the perfect monetization target.
Monetization Design & Store Strategy Basics
You can use Location and Net Worth as vectors for scaling, contextualizing, and segmenting everything, incl. IAP offer and Store layout/offers basics as well as Events.
Offer & Store Layouts
Event-Driven Stores: Store contents shift based on live events, offering:
Event-boosting bundles (e.g., Dice Rolls + Event Tokens).
Specific upgrade packs.
Progression multipliers.
And such.
Contextualization / segmentation by Location_ID & Net_Worth:
Players in early Locations see cheaper, time-limited bundles.
Deep players get high-value packs scaled to their sink requirements.
And much more.
Event Integration for Monetization
You can drive monetization-led integration for your events through your vectors.
In a nutshell:
Events serve as short-cycle “heartbeat spikes” in player activity.
Early entry events give generous Dice Rolls to hook players.
Carry-over Mechanic: Rewards from one Event provide a head start in the next, creating a perpetual loop of participation.
Live Events as Economy Drivers
Heartbeat Effect
Event spikes map directly to peaks in player engagement and spend.
Between events, activity settles at a sustainable baseline, keeping churn low.
Scaling with Progression
Event difficulty and rewards could theoretically scale with your vectors, Location and Net Worth, ensuring relevance / contextualization.
Event sinks could be are layered on top of location sinks, maintaining pressure on Dice Rolls.
Config-Level Mastery: How to Operationalize the System
Using Location_ID and Net_Worth as configuration anchors allows for e.g.,:
Dice Outcome Tables: Control RNG by weighting key outcomes per Location (less random, more predictable balancing).
Progression Curves per Location: Adjust sink/source balance dynamically without reworking the whole game.
FTUE & Narrative Control: Tailor tutorials, challenges, and rewards for optimal early retention.
Board Layout & Tile Setup: Dynamically adjust board difficulty and pacing based on player progression.
Bot & Player Pools: Match players against AI or real opponents suited to their current scale.
IAP Offer Configs: Offer IAP offers based on progression contextualization.
Store Configs: Adapt Store layout and offers based on progression contextualization.
Configuration Table Examples
I always like to have a fully scalable, and configurable games being made, with systemic interconnectivity. For a game like Monopoly GO!, it’s achievable, as explained, pretty easily. Below you can see few imaginary examples of how you could build simple configuration tables for easily configuring and scaling everything through your backend.
Example 1. Configuration table example for Board Layout controlling. Location_ID / Location-based Progression acts as main anchoring point. Parameters and numbers here are thrown out from thin air to the table.
Example 2. Configuration table example for Building mechanic (scaling) controlling. Location_ID / Location-based Progression acts as main anchoring point. Parameters and numbers here are thrown out from thin air to the table.
Example 3. Configuration table example for imaginary Store layout configuration (following e.g., Location_ID anchoring for contextualization). With having a layout configuration table like this, in addition to changing the store and its layouts and sections based on Progression contextualization and ongoing Events, you can place e.g., via other interconnected configuration tables your offers (Bundle_IDs) to these placements (to their representative sections). And, if you use e.g., pools for rewards pooling, you could use e.g., Pool_IDs (representing different reward pools you’ve created) to place your pools consisting of offers / rewards into these sections. Parameters and numbers here are thrown out from thin air to the table, and the imaginary layout isn’t actually what’s represented in Monopoly GO!, but it’s acting as an example of how you can build configurability / modularity / contextualization for your Stores.
Coin Master, Dice Dreams, and Other Games
These games can also use identical vector anchoring strategies:
Location progression serves as the macro driver.
Equivalent vector to Net Worth gates reward scaling, mechanics, and such.
Dice Roll / Spin resources act as the primary monetization lever.
Events echo the main progression curve, reinforcing core loop monetization.
The Role of Mathematical Modeling and Control
While advanced economy modeling is ideal, this system allows for:
Lightweight Implementation: Designers can define progression through e.g., pre-set Diceo outcome tables and scaling curves per Location_ID.
Data-Driven Refinement: Live data will reveal where sinks/sources need adjusting, and where segmentation for player archetypes becomes necessary.
Whilst there are some space for math, there are also options where you can do a lot without advanced math with this vector anchoring approach. These games can be in a simple format super simple to build and optimized without heavy math, whilst they sustain high revenue potential. Complexity of course raises as you advance with your take, when Events, segmentation, and other things take in place.
Plus, when / if you go in using Seeds, which might give you some leverage, there are lots of other considerations you need to count for. But do you need them? Technically you can benefit from them but also on the other side you could control things with other means instead of Seeds as well, or Seeds-like systems / configurations achieving the same, as you want. Seeds could be also used only for some necessary parts of the overall systems-based approach, e.g., offer logic and game behavior, but same things could be also triggered by kind of the same means as you would be able to configure things with the fundamentals of where you can go from simplistic interconnectivity.
Key Takeaways
Location and Net Worth, if you like to strategize the game from systems perspective this way, can indeed serve as universal scaling levers for the game. Early MVP can function with simple exponential sink + linear source curves; whilst full-scale live ops can layer complex scaling, segmentation, and event hooks.
Dice Rolls are the ultimate monetization currency — control them carefully through progression and events. Live events not only engage players but also synchronize economy pressure with monetization opportunities.
This is how you can, in one way, approach building a game like this. Can you use similar methods for other games? I’d say yes, and you can read about such a thing here (https://gamesalchemy.substack.com/p/51-designing-around-progression-vectors):
It will be interesting to see what types of games we’ll be seeing in this segment as the days pass. Coin Master - Board Adventure is one of the most fresh takes on the segment, whilst I see there are more great opportunities ahead. Mechanics can vary, as you can use these strategies and methods for building a high variety of different types of games.