Merge Mechanics: Grid Retrieval, Type Validation, and Item Spawning
A deep dive into the core mechanics of merge-based casual games, covering grid retrieval, type validation, and item spawning logic. The article details the complete design loop from gameplay objectives to the economic system, analyzes balance challenges in merge rules and UI interaction nuances, and provides scalable directions for content production to help developers build robust merge mechanics.
Breakdown
- Upgrade low-tier items into higher-tier items through merging, ultimately unlocking the highest level or rarest item.
- Maximize output efficiency under constraints of limited grid slots and resources like energy or stamina (yield per unit time).
- Drive output routes via tasks or orders: produce Item A first, then merge to create B, fulfilling orders to earn currency and progress.
- Spawning: Click or build structures to generate base items (subject to stackable cooldowns, stamina limits, or production rates).
- Merging: Drag two items of the same level -> upgrade to the next level (+1).
- Consumption: Fulfill orders/unlock areas/upgrade buildings to reclaim grid slots and receive rewards.
- Growth: Use rewards to boost production speed, increase grid capacity, improve merge efficiency, or unlock new chains.
- Matching Conditions: Items must share the same type and level to merge (or allow merging by rarity).
- Result: Generates a new item at level+1; original items are consumed.
- Failure/Block: Merging is blocked if levels differ; also blocked if the target grid slot is occupied or locked.
- Protection: Real-time preview of merge results during drag; release to confirm; undo can serve as a monetization point.
- Spawning Points (Generators) produce base items based on cooldowns, or items can be generated by consuming stamina via click.
- Drop weights are configurable: common items, rare items, and event-specific items.
- Spawning is affected by upgrades: reduced cooldowns, increased yield, and unlocking higher initial levels.
- Order Requirements: Submit specified items (can span multiple merge chains).
- Reward Structure: Base currency + experience + milestone rewards (chests/keys).
- Order Refresh: Timed refresh or manual refresh (monetization point) to maintain player goals.
- Grid Pressure: Early game has few slots, forcing delivery/organization; later stages relieve pressure via grid expansion.
- Cooldown Pressure: Generator cooldowns force players to plan merge routes strategically.
- Chain Depth: Merge attempts for higher levels grow exponentially, balanced with acceleration or multiplier items.
- Drag Interaction: Highlight 'Mergeable' when hovering over same-type/same-level items; otherwise show 'Swap' or 'Place' options.
- Tooltips: Long-press to view item info, merge chain preview, and next-level product.
- Anti-Mistake: Synthesis confirmation threshold (drag distance/dwell time) or one-step undo.
- Multiple Merge Chains: Food chain/Tool chain/Decor chain, with orders combining across chains.
- Events and Buffs: Limited-time double yield, merge critical hits (level skip), rare drop weeks.
- Map Areas: Unlock new regions to open new merge chains and order pools.
Key Code
Demo
No dedicated demo yet — embedded the minimal playable example of its archetype instead.
Article
Merge Gameplay from 0 to 1: Rules, Data Structures, and Scalable Architecture
The Essence in One Sentence
On the surface, it's about judging whether a merge is possible; in reality, the core mechanism is decision-making for drop behavior based on the priority order: "empty space first, then merge, and swap last." This article focuses on explaining how to implement this decision chain using pure functions.
> Article Goal: Use a "reusable implementation approach" to get the merge gameplay running, and provide entry points for subsequent expansions (orders/producers/payment points/balance).
1. Gameplay Overview (Player Perspective)
The core experience of the merge gameplay is: Production → Merge & Upgrade → Clear Space / Deliver Goal → Gain Growth.
A minimum playable loop: 1) Generate base items (clicking / producers) 2) Drag two identical items to merge and upgrade 3) Use higher-level items to complete orders or unlock goals 4) Use rewards to upgrade production / grid slots / rules
2. Rule Design (MVP Rules Fixed First)
This session covers only the most basic rules (extensible but not implemented yet):
- Match Condition: Items can only merge if
typeandlevelare identical. - Merge Result: Generates a new item with
level + 1, consuming two old items. - Drop Behavior Priority: Merge > Swap > Move to Empty Space.
- Prohibited Conditions: Target cell locked / Source cell empty / Target cell non-interactable.
2.1 Why "Priority"?
Without defined priorities, drag-and-drop interactions feel random to players: The same operation might sometimes merge, sometimes swap, or sometimes fail to move. Therefore, the drop rules must be written as explicit judgments at the code level.
3. Data Structures (Minimal but Scalable)
I suggest splitting the "gameplay data" into three layers:
3.1 Item
id: Unique identifier (used for animations/tracking)type: Merge chain (e.g., flower / weapon / animal)level: Level- (Optional)
rarity: Rarity (for later expansion)
3.2 Cell (Grid / Inventory)
iditem: Item | nulllocked?: boolean(can be used for area unlocking in the future)
3.3 Config
- Merge Chain: Max level for each
type, display name, icon, etc. - Merge Rules: Whether skipping levels is allowed, whether "critical merge" is allowed.
- Generator Rules: Production interval, produced items, initial level, drop weights.
4. Core Merge Logic (Most Important)
The logic below is recommended to be implemented as pure functions for ease of testing and reuse:
Edge Cases
- Must handle returning failure with a reason when the source cell is empty.
- Must handle returning failure with a reason when the target cell is locked.
- Must prioritize executing the move operation when the target cell is empty.
- Must prioritize executing the merge operation when the target cell item matches the source cell item in both type and level.
- Must execute the swap operation when the target cell item does not meet the merge conditions with the source cell item.
Design Trade-offs
- Benefit: Code written as pure functions is easier to test and reuse.
Cost: The logic judgment order must be hardcoded and cannot be dynamically adjusted.
- Benefit: Using the
DropResulttype uniformly covers the three outcomes (move, swap, merge).
Cost: Every drop action requires traversing and judging all three scenarios.
- Benefit: Supports later expansion of skip-level or critical merge rules.
Cost: Basic rules are fixed in the MVP phase without expansion.
You may also like
A deep dive into merge and upgrade mechanics, breaking down merge rules, production pacing, and in-game feedback loops. The article outlines the implementation path from gameplay goals to core loops, offering reusable data structures and key numerical design principles to help developers build accessible, high-growth idle merge systems.
A deep dive into the Merge Evolution mechanic, breaking down hierarchical chain design and rarity drop mechanics. We quantify the numerical balance of blockers and unlock thresholds, offering controlled pacing strategies to prevent player churn and build high-retention merge chains.
Deep dive into the mechanics of one-line drawing puzzles: using Euler path logic to validate solvability and controlling node degrees to generate unsolvable or single-solution levels. Systematically explains how branching points and loops quantify difficulty, demonstrating how algorithms dynamically add misleading edges to boost challenge. Readers will master graph theory applications in level generation and learn to build playable, clearly tiered puzzles.