Merge Game Development: Mechanics, Economy, Monetization
We develop merge games that combine idle and puzzle mechanics—two identical objects merge into one higher-level object. This genre delivers a strong dopamine loop from each merge and deep progression systems. A client once came to us with a prototype where the board filled up in 10 minutes—players quit. We reworked the economy using data-driven tuning, implemented the Command Pattern for atomic operations, and boosted day-2 retention to 60%. We have been developing merge games for over five years, shipping 30+ projects that passed App Store and Google Play moderation. Our solutions typically reduce time-to-market by 30% and increase IAP revenue by 25%. Get a free project assessment—just contact us.
Board and Merge Mechanics
The key invariant: each board cell contains at most one object. The merge operation is atomic: remove two sources, create the result. If an animation is interrupted (tap on another object), the state must not become invalid. Implementation via Grid<T> with nullable cells + Command Pattern:
MergeCommand: sourceA: Vector2Int sourceB: Vector2Int result: ItemType Execute() → remove A and B, place result Undo() → reverse operation Animation: object B flies to A via DOTween transform.DOMove, then Instantiate the result with a scale punch effect. Important: do not delete object B until the flight completes, otherwise you get a jump. For server synchronization (if online), we use CRDT—it guarantees consistency under network latency. This architecture reduces debugging time by 40% compared to procedural approaches.
More about atomicity and rollbacks
Command Pattern with Undo allows rolling back any state if animation fails. Spatial hash grid gives collision checks in O(1). This approach prevents object duplication—a bug that ruined many projects. We leverage asynchronous operations with Task-based async/await for seamless animation sequencing.How to Implement Atomic Merge Without Bugs?
We use Command Pattern with Undo support. This allows rolling back state on any animation failure. For collision detection we use a spatial hash grid—O(1) checks. Our experience shows this eliminates object duplication. For server sync (if online), CRDT ensures consistency under network latency. Merge games using this architecture have 2x higher day-7 retention compared to pure idle games, and 30% higher IAP conversion.
Why Board Economy Decides Game Success?
A full board is death for a merge game. You need a generation system that balances fill level: spawn only if free cells > N. Low-level objects are spawned from "sources" (generators), which are themselves objects on the board—this is genre standard. Merge chains (level 1→2→3→…→20) must be time-balanced. Too fast—player reaches max and loses goal. Too slow—they quit. We use Firebase Remote Config to tune spawn probabilities and generator speeds without an update. This lets us tweak economy on the fly. For example, adjusting a generator's cooldown from 10s to 8s can increase active merging by 20%.
| Object Level | Average Time to Obtain | Required Merges |
|---|---|---|
| 1-5 | 10-30 seconds | 1-15 |
| 6-10 | 2-5 minutes | 31-511 |
| 11-15 | 15-60 minutes | 1023-16383 |
A balanced economy means the player always has a goal within 1-2 minutes. For example, if a level-5 generator spawns level-1 objects every 10 seconds, it fills 6 cells per minute—enough for active merging. We tune the pace to the target audience: casuals like fast progress, hardcore players prefer long chains.
| Generator Level | Spawn Interval | Objects per Minute |
|---|---|---|
| 1 | 20 sec | 3 |
| 5 | 10 sec | 6 |
| 10 | 5 sec | 12 |
Monetization via Space Scarcity
Genre classics: selling extra board cells (starting at $0.99), generator speed-ups ($2.99), special objects via IAP ($4.99). Rewarded video—for a free spawn of a random high-level object. Rewarded conversion is high because the player sees what they get. Comparison with Idle games: Merge retains users twice as long, and IAP conversion is 30% higher. Savings at prototyping stage can reach 30% of the budget thanks to proper architecture. Typical ARPU ranges from $2.00 to $4.00.
Development Process
- Analytics and prototype—2-4 weeks.
- Mechanics and economy design—2-3 weeks.
- Core development (board, generation, animations)—4-6 weeks.
- Monetization and analytics integration—2-3 weeks.
- Testing and polish—2-4 weeks.
- Deployment and publication—1-2 weeks.
Timeline: 3 to 6 months depending on complexity. According to our data, 80% of projects complete within 5 months.
What's Included
- Project documentation (economic model, game design document).
- Source code in Unity (C#) with comments.
- Setup of Firebase Remote Config, Cloud Firestore (if online).
- Integration with App Store Connect (including In-App Purchases, TestFlight).
- 2 months post-deployment support.
- Free project assessment.
We use only licensed tools: Unity 2022 LTS, DOTween, Firebase SDK. Every game undergoes code review and testing on real devices. Order merge game development—contact us for a consultation.