Match-3 development: where the game loop breaks
A prototype with a dozen levels looks healthy: the board assembles, cascades resolve, level goals align.
The problem shows up in the mid-game: completion rate drops from the expected two-thirds to one-third, and the number of attempts per level grows faster than the difficulty curve allows.
The cause is usually in the generator. It lays out pieces and checks the starting board for available moves, but doesn't recalculate solvability after cascade and refill: the board reaches a state with no matches and no valid move. Reshuffle at that point breaks pre-placed obstacles — the level turns into another level.
The second layer is the order of steps in the puzzle game loop. Move validation placed at the end detects a deadlock after the move animation.
The piece matching algorithm must work together with the generator: during refill, it evaluates not only the current match but whether valid moves remain one or two steps ahead.
Match-3 level balance and the difficulty curve are usually assembled manually by feel: move limits, goals, and obstacle sets are locked before data on real playthroughs exists.
The in-game economy issues resources by one model while players spend by another — by mid-game the discrepancy becomes noticeable, and spot fixes to individual levels don't close it.
We break down how this is closed: from a generator with guaranteed solvability to balance tables rebuilt from playthrough data.
What core rework delivers: retention and completion rate
The match-three core is the board generator and move-search rules, not swap animation. When the generator doesn't check the board for valid moves, the player gets stuck: pieces exist, combinations don't.
Deadlock-free board generation is basic hygiene: after every fall and void fill, a move search runs, and if none exist, the board is rebuilt from the same seed until at least one valid swap appears.
The second layer is the difficulty curve. Instead of manually editing levels one by one, we define several axes: goal, move limit, piece set, obstacles, bonus frequency.
This gives progression depth where level completion rate grows smoothly, and on difficult sections you can see exactly where players drop off.
Puzzle game retention rests on the first sessions. If on level ten a person hits an unreachable goal several times, there won't be a second session.
After reworking the level grid, the share reaching the end of the tutorial block grew, and mid-level drop-off stopped being a cliff.
Animation stability is a separate workstream.
A cascade of bonuses causes a spike in computations and frame drops on weak devices: we limit cascade depth, compute board state before visualization starts, and profile on real hardware — Unity is our main tool, but decisions are made from measurements, not feel.
The result is measurable: no deadlocked boards across the entire level set, a level is prepared for display faster, and day-two and day-seven return rates grew with the same player traffic.
Match-3 game development options and their limitations
Before choosing a stack, define the source of mechanics: it determines how much time balancing will take and how painful it will be to port the game to a second platform.
Board, cascades, match collection, and hint logic are the core, and it determines which changes are even possible.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made mechanics set | Need a fast launch on a proven grid and cascades | Level logic is closed: can't add custom assembly rules and non-standard bonuses, level generator comes bundled and is almost non-configurable |
| Own game core | Custom mechanics, server logic, and long-term support are planned | Slower and more expensive at the start: we write move validation, cascade resolution, reward tables, and win conditions ourselves |
| Hybrid approach | Need custom bonuses or a level generator on a ready-made base | Third-party code must be synchronized with your own rules on every set update |
A separate point is the level generator: it determines whether the game is expanded by a game designer or whether every level needs an engineer.
Portability to another platform is laid down at this same stage: if the board, moves, and progression are described by data, not spread across screens, the second platform gets the same logic and a separate rendering layer.
Work stages: from mechanics breakdown to release
We develop match-3 from the project's current state: first we measure what already works, and only then change code. That's why core assembly doesn't start by rewriting working parts, and balance decisions are made from numbers, not feel.
- Game prototype audit. We measure board response to swipe and cascades, run the generator for deadlocked layouts, capture level playthroughs and player drop-off points.
- Game architecture design. On a dependency diagram, we separate the game core — board generation, match search, gravity, cascades — from interface, data, and analytics layers. Rules are verified by tests without launching the app.
- Game core assembly. Deterministic generation by seed, object pools instead of constant instantiations, session recovery after app backgrounding.
- Balance tuning. Piece weights, level goals, move limit, difficulty curve. The simulator runs levels thousands of times and outputs success rate and deadlock frequency — edits are based on these numbers.
- Test builds. Closed player group and internal runs: per-level analytics events, completion rate, attempt count, returns to the game.
- Project acceptance. Source code, architecture diagram, generator documentation and balance tables, instructions for releasing updates and troubleshooting failures.
This order saves weeks on rework: bottlenecks are found before release, not in reviews. After that, the project lives in a working cycle — new levels and mechanics fit into the ready scheme without rewriting the core.
Project artifacts: source code, balance tables, regulations
After handover, the project must not depend on us. That's why the delivery includes not a built build in the contractor's closed dashboard, but a repository with full change history, reproducible build, and data your team edits independently. Below is the list of what is recorded in the acceptance act and remains with the client.
- Game source code — repository with commit history, build instructions, and environment settings; release branch is separated from development branch, access is granted to your engineers.
- Balance tables — configurations in readable formats (CSV, JSON): per-level rewards, booster and hint costs, difficulty curves by episode. Edited without rebuilding the app.
- Level generation rules — description of the piece layout algorithm, solvability and cascade criteria, plus the generator and validator scripts themselves with example runs.
- Economy and progression schemes — currency flows, monetization points, relationships between level difficulty and player retention in the first session.
- Project documentation — client and server architecture, save formats, list of external services and their role in the game loop.
- Update regulations — version release procedure, save compatibility rules between builds, and rollback procedure to the previous release.
- Acceptance and monitoring instructions — procedure for testing new levels, set of funnel metrics, and setup of failure alerts in production.
This package allows you to grow the game with your own team or hand it to another contractor without reconstructing logic from indirect signs.
Case study: relaunching the level grid in a live game
Mobile game case study: a grid of several hundred levels shipped, but completion rate dropped in steps, not smoothly. On some levels, win rate held at 12-18%, players burned out by attempt thirty to sixty and closed the app.
Event export to GameAnalytics showed: about 70% of drop-off came from twenty "bottleneck" levels across the entire grid — meaning it wasn't about overall difficulty, but specific board layouts.
How levels were reworked without stopping the game
We broke down the grid by difficulty curve: for each segment, we set a target win rate (75-80% on early levels, 45% in the middle, 25% at peaks) and compared it with actual.
The board generator got solvability validation — before issuing a layout, it is run through solution search, and combinations where the goal is unreachable without a paid booster are discarded.
At the same time, we raised the value of regular moves: adjacent matches more often produce chains, and a level is completed in fewer moves.
To avoid stopping the live game, the level set was moved to a remote versioned settings file and rolled out in batches of twenty to 10% of the audience. Rollback to the previous set is one operation, without rebuilding or publishing to app stores.
Result: win rate on problem levels rose to 46%, mid-grid drop-off fell almost by half, and next-day repeat sessions gained nine percentage points. Match-3 development after release is balance work, not catch-up content edits.
How does a cascading grid differ from honest falling physics?
A cascading grid and falling-piece physics diverge in what happens after pieces are cleared.
In the cascade model, the board is a matrix of integer coordinates: an element disappears, the ones above shift down a row, new ones pour in from the top, and the next cascade resolves in the same tick.
In the physics model, a piece gets velocity, falls with acceleration, and collides with neighbors — landing order depends on the simulation step.
Hence the difference in board predictability. A cascading grid is deterministic: the same sequence of moves produces identical combinations on any device, because the state is described by an integer matrix and doesn't depend on frame rate.
Physics provides no such guarantee: under different CPU load, pieces land differently, and identical combinations diverge across devices. For a networked game, this costs state synchronization and rollbacks.
The second consequence is the feeling of fairness. In a cascade, the player sees what will fall into which column and plans two or three moves ahead, and a loss reads as their own mistake.
Where the result depends on collisions, the same plan works every other time, and planning is replaced by guessing — this is the first thing complained about in reviews.
The choice is usually predetermined by mechanics. If the core is a puzzle with planning and leaderboards, use cascade: board state is reproduced in replay, verified on the server, and protected from result tampering.
Physics is added for spectacular collapse and bonuses with mass clearing — then the simulation is run with a fixed step, and discrepancies are smoothed out with state snapshots.
FAQ on mechanics, balance, and support
Deadlocks, divergent balance, a prototype on a ready-made game builder — these doubts come up before the start. Below are short technical answers: how we test mechanics, what data we collect, and what remains with the client.
How do you find deadlocks on the board?
We run levels with a bot: thousands of games across different strategies reveal boards where no moves remain or the goal is unreachable. We separately test the generator for rare layouts so the board doesn't get stuck at the start.
Will balance have to be rewritten after launch?
Not from scratch. We store balance in tables, not code: goals, move limit, piece weight, and bonus drop chance are edited without rebuilding. After changes, the bot reruns the levels and compares completion rate.
Can a prototype from a ready-made game builder be ported?
Yes. We break down the prototype's scenes and mechanics, port the logic to the current Unity branch, and compare it with the original using control playthroughs. Balance and levels are preserved; we rewrite the save and analytics architecture.
What is included in support handover?
Repository, balance configs, data schemas, build and release instructions, access to app stores. Your team can run the project independently — we break down bottlenecks.
How is analytics connected?
We build a funnel: install, tutorial, first win, level drop-off, returns, payments. We name events according to a single schema so per-level and economy reports reconcile without manual stitching.
Let's discuss the task: mechanics, scope, team composition
To come back with a scope estimate and stage plan, we need inputs — without them, any estimate turns into a wide range for timeline and team composition.
The more specific the materials, the fewer assumptions in the plan and the more accurately we can state the effort required for each part: board mechanics, interface, economy, server side.
What to send and what to clarify at the start:
- Platforms and device coverage: smartphones only or also tablets, screen orientation, minimum supported OS version — this determines the scope of interface adaptation.
- Prototype materials: level sketches, game board schemes, visual style examples, description of match and piece-fall mechanics. If there is a playable mockup, we analyze it first.
- Level rules: board size, piece and bonus set, win and lose conditions, move limit, and board behavior when there are no matches.
- Monetization: ads between levels, in-app purchases, subscription, or a combination — this determines the progression scheme and difficulty curve.
- Team composition: which roles you cover (game design, art, analytics) and which we take on. This directly determines the stage plan and approval points.
- Constraints and project start: desired deadlines, publishing platform requirements, ready developer accounts, access to your systems.
After the breakdown, we'll return with a scope estimate, a stage plan for prototype, production, and launch, and a proposal for team composition. Describe the task — we'll schedule a business call.