Game Economy Design from Match-3 to Strategy: Preventing Inflation and Balancing Resources

We design balanced economies for mobile games, from match-3 to strategies. If resource sources exceed sinks, inflation sets in: the player accumulates currency faster than they can spend it, prices lose meaning, and IAP becomes unattractive. If sinks are too aggressive, the game feels pay-to-win and loses its audience. Our approach is numerical design pre-launch, not post-launch fixes based on feedback. Our team has experience with 10+ mobile game projects and 5 years in game design.

A well-tuned economy is invisible to the player. They don't think about balance — they think about what to buy next. We guarantee calculation accuracy using proven tools: Google Sheets with progression formulas and Machinations for simulation.

The Currency System as Foundation

Most mid-core games use a dual-currency architecture, but it's often implemented with flaws. A typical problem: overly generous soft currency sources.

The player earns 500 gold per level, but an upgrade costs 300. After a week, they have 50,000 gold, and they realize the in-game money is worthless. When offered 1,000 gold for $1.99, it feels absurd — they already have a full wallet.

Fixing this post-launch is extremely difficult: you can't just "make gold more expensive" — existing players will revolt. So balancing must be done before launch, on paper.

Designing Sources

Each resource source is classified by:

• Predictability: regular (daily login) vs. random (mob drop)
• Dependency on activity: active (level completion) vs. passive (farm, timer)
• Quantity: fixed vs. variable (with randomness)

To forecast the economy, we build a norm table: how much a player earns per day at casual, average, and hardcore activity levels.

Sinks: Where Currency Goes

Rule: each currency type must have a regular and attractive sink. If soft currency is only spent on content that can be completed in two weeks, it becomes useless afterward.

Good sinks for soft currency:

• Upgrades with increasing costs (each level 1.5–2× more expensive than the previous)
• Consumables in constant demand (potions, ammo, energy)
• Daily rotating offers in the shop

Good sinks for hard currency:

• Timer skips
• Slot unlocks (inventory, construction queues)
• Exclusive content purchases (skins, units)
• Continue after defeat

How to Prevent Inflation in Game Economies?

Hard caps: a limit on the maximum amount of currency that can be held without IAP. For example, maximum 10,000 gold without a "wallet." Players who hit the cap must spend or buy storage expansion.

Limited-time events: events with exclusive rewards create temporary scarcity — players spend their hoarded currency on event content. Flash sales work on the same logic.

Decay mechanics: currency earned through passive sources (farm) stops accumulating after reaching capacity. This forces players to log in regularly and spend.

Numerical Design: Calculation Example

Let's say we have a match-3 game with levels. Parameters:

• Average level length: 2–3 minutes
• Average session: 20–25 minutes = 8–10 levels
• Lives: 5, recharge 1 life / 30 minutes

Gold sources per session (casual player):

• 8 levels × 50 gold = 400 for completion
• Daily bonus: 100 gold
• Total: ~500 gold per day

Sinks: extra lives via IAP or gold (150 gold = 1 life), booster (200 gold). If the player spends an average of 2 lives/day = 300 gold. Surplus: 200 gold/day — an additional sink or source reduction is needed.

After balancing, we add a "double drop on weekends" event — this doesn't break the economy but creates a reason to play more actively.

Why the Monetization Cliff Matters?

The monetization cliff is the point in the game where free progress sharply slows down and the player hits a wall. Either they pay, grind for hours, or leave.

The right approach is not a wall but a slope: progress without payment is possible, but payment makes it significantly more comfortable. The difference between "pay or suffer" and "pay or go slightly slower" is critical for long-term retention.

Designing the cliff requires knowing the progression curve: at what level does average difficulty exceed average player skill? That moment is a point of suggestion, not a wall.

Resource Economy in Strategies

In strategies (builder, 4X), the economy is more complex: multiple resource types with different production rates, dependencies, and timers.

A key tool is the resource matrix: a table where rows are resource types, columns are sources and sinks. For each cell: quantity, condition, frequency. This reveals imbalances before implementation.

Example: if wood and stone are gathered at the same rate, but stone is needed 3× more for upgrades, stone becomes a bottleneck. That's not necessarily bad, but it must be a deliberate design decision, not an accident.

Design Tools

We design economies in Google Sheets with progression formulas, not in our heads. Basic model: columns are days (1–30), rows are sources/sinks/balance for each currency type. Three scenarios: casual, average, hardcore.

For complex economies, we use Machinations — a visual language to simulate game economies without code.

What's Included in Economy Design

The deliverable includes:

• Currency system documentation: currency types, conversions, limits
• Source and sink table with 30-day simulation for three scenarios
• Progression curve with monetization points marked
• Description of anti-inflation mechanics
• Technical specification for developers
• Post-implementation consultation (up to 2 hours)

Our experience: 10+ projects for mobile games, 5 years in game design. We guarantee the economy will be balanced pre-launch and won't require emergency post-release fixes.

Work Stages

1. Analyze genre and game mechanics — what the player does, what resources are needed for progress
2. Design currency system: number of currencies, types, conversions
3. Map sources and sinks with daily balance calculation
4. Progression and monetization curve
5. Anti-inflation mechanics
6. Numerical models in a spreadsheet with 30-day simulation
7. Technical specification for the development team

Design time for a basic economy: 3–5 days. Comprehensive multi-resource economy for strategy or RPG: 1–2 weeks. Cost is calculated based on scope and complexity. Contact us — we'll evaluate your project within one business day.

Mobile App Monetization: IAP, Subscriptions, and Ad Mediation

An app with poorly implemented purchases loses money not because users don't want to pay, but because a StoreKit transaction hangs, Receipt Validation fails with an error, or restore purchases doesn't work — and the user writes to support or leaves a 1-star review. Our experience (over 7 years in mobile development) shows that proper monetization increases LTV by 30–60% within the first three months after implementation. Get a consultation on monetizing your app — we'll analyze the current model and find growth points.

Why StoreKit 2 is the Best Choice for IAP?

StoreKit 2 (iOS 15+) is a modern API with async/await and device-side verified transactions without a server. Transaction.currentEntitlements returns all active purchases. Key change compared to StoreKit 1: JWS signature verification on device via VerificationResult<Transaction> — no need to send receipt to server for basic validation.

But server-side validation is still needed for consumable purchases and fraud prevention. App Store Server API replaces the old /verifyReceipt endpoint. Webhooks via App Store Server Notifications v2 provide real-time events: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — without polling.

A typical mistake: not handling paymentQueue(_:updatedTransactions:) in the background for unfinished transactions. User bought a consumable, app crashed before finishTransaction — purchase remains in queue, restores on next launch and requires reprocessing on server. Without server idempotency — double crediting.

How Not to Lose Revenue on Subscriptions?

The subscription model requires tracking states: trial → active → grace period → expired → refunded. RevenueCat is the de facto standard for managing subscriptions in production. It abstracts StoreKit and Google Play Billing, providing a unified API, webhooks, cohort analytics, and A/B testing of paywalls.

Alternatives to RevenueCat include custom implementations with Adapty or Qonversion. Fully custom only if data must not leave the infrastructure or there is non-standard logic. We guarantee that webhook setup and subscription lifecycle event handling is done without losses — verified on projects with over 500k DAU.

Google Play Billing Library 6+ requires handling PurchasesUpdatedListener and explicitly calling acknowledgePurchase() or consumePurchase() within 3 days — otherwise Google automatically cancels the purchase and refunds. The average cost of such an error is a significant loss per user per month (based on our project data).

Ad Mediation: Boosting CPM via Bidding

Showing ads from a single source means losing revenue. Mediation (waterfall or bidding) requests ads from multiple networks and displays the best bid. Google AdMob is the foundation for banner, interstitial, rewarded ads. Mediation via AdMob Mediation or MAX (AppLovin) is the second de facto standard. MAX uses In-App Bidding — a real-time auction without waterfall. In practice, MAX yields significantly higher CPM than classic waterfall (depending on geo and audience). For example, for rewarded video in the US, the improvement can be substantial. With 100,000 rewarded video impressions per day, switching from waterfall to In-App Bidding can generate additional daily revenue.

ironSource (Unity Ads) has a strong position in the gaming segment, especially rewarded video. Mintegral covers the Asian audience well.

Setting up mediation requires ATT (App Tracking Transparency) on iOS 14+. Without requestTrackingAuthorization, ad CPM drops by 3-5 times for non-consenting users. SKAdNetwork and Privacy Manifest (iOS 17) are mandatory requirements; without them, review fails.

How We Implement Monetization: Step-by-Step Process

1. Current model audit — analysis of funnel, paywall, price tiers, and identification of bottlenecks.
2. Model design — choose type (subscription, consumable, non-consumable) and optimize price points.
3. IAP integration — set up StoreKit 2 / Google Billing 6, receipt validation, webhooks.
4. Ad mediation — connect 3-6 networks, configure waterfall or In-App Bidding, test fill rate.
5. Analytics and cohorts — integrate RevenueCat, Amplitude, or Firebase for LTV tracking.
6. A/B testing of paywall — use Remote Config for experiments without a release.
7. Launch and monitoring — 2 weeks of free support after launch, bug fixes by 24-hour SLA.

How to Design a Freemium Model and Paywall?

Freemium works when the boundary between free and paid is properly drawn. Too strict a paywall at the start — users delete. Too generous a free tier — no incentive to pay.

A technically sound pattern: server-side feature flags (Remote Config in Firebase or LaunchDarkly) control access to features. This allows A/B testing of paywall without a release, changing trial conditions, and running promotions.

Implementation at the code level: EntitlementManager — a single point for checking access to features, aware of subscription status, flags, and promos. No scattered isPremium checks throughout the code. Experience shows this approach reduces paywall-related bugs by 80% (confirmed on 30+ projects).

Scope of Monetization Work

• Current model audit — analysis of funnel, paywall, price tiers.
• IAP integration — StoreKit 2 / Google Billing 6, receipt validation, webhooks.
• Ad mediation — configure MAX / AdMob, connect 3-6 networks, test fill rate.
• Analytics setup — RevenueCat, Amplitude / Firebase, cohort analysis.
• Documentation — description of entitlements, restoration procedure, review checklist.
• Team training — analysis of typical mistakes, support recommendations.
• Guarantee — 2 weeks free support after launch, bug fixes by 24-hour SLA.

Estimated Timelines

Cost is calculated individually. We have been working in this field for over 8 years and have implemented monetization in over 40 projects — many of which passed App Store Review without a single rejection. Contact us for an audit or order a consultation — we'll tell you what growth points exist in your app.