Game Development

Sprung Blast

Beta In Development

A mobile block puzzle where cleared lines launch springs that push, chain and set up the next move — now in beta.

Role
Solo Developer · Game Design & Development
Year
2026
Engine
Unity · C#
Tools
  • Unity 6
  • C#
  • URP 2D
  • Input System
  • NUnit
  • iOS
  • Android
Sprung Blast cover image
  • Designed the spring, push and chain rules on top of a familiar 8×8 block puzzle
  • Built a deterministic rule core in pure C#, kept fully separate from Unity
  • Designed and built a Roguelike mode — eight floors, combo-driven perk picks and a perk codex
  • Balanced both modes with bot simulations, then shipped a beta with an in-game bug reporter
Contents

Context

Sprung Blast is a portrait mobile puzzle game for iOS and Android, made in Unity. I am designing and building it on my own, and it is currently in closed beta. The source code and assets are not public while the game is heading towards release, so this page covers the design and the systems through screenshots and a write-up rather than the code itself.

The starting point is a genre everyone already knows: drag pieces onto an 8×8 board and clear full rows and columns. The question I wanted to answer was whether one extra rule could give that familiar move a second consequence without asking the player to learn a whole new game.

One line: place blocks, clear lines — and every cleared spring bounces, pushes and chains into the next one.

The Core Idea

Some blocks are springs. Each one carries a direction and a distance from 1 to 3. When a spring’s line is cleared, it jumps that far in that direction:

  • Push — instead of ignoring what is in the way, the spring shoves the row of blocks in front of it. A clear stops being only a removal and starts rearranging the board.
  • Chain — if a spring lands on another spring, it triggers it, and that one bounces in turn. One good placement can resolve as several waves.
  • Two kinds of spring — fixed springs arrive with a random direction, so the decision becomes “where do I place this piece so that its spring is useful?” Purple springs are rarer and let the player aim them. They are a scarce resource to hold on to, not a free choice every turn.

Distance is shown by colour (yellow, orange, red) and by a number on every spring, so the rule never depends on colour alone.

A combo system keeps the tension up: clearing at least once per tray of three pieces keeps the combo alive, and a chain of waves pushes it further.

Two Modes

  • Classic — an endless high-score run. Runs are saved on every move, so the game can be closed at any point and picked up exactly where it was left.
  • Roguelike — a run through eight floors. Each floor has a score target to reach within five trays, and filling the combo bar offers a choice of three perks that bend the rules: longer jumps, more purple springs, combo shields, chain bonuses. Taking a perk you already own levels it up. Perks you have found are recorded in an in-game codex. There is no permanent power progression between runs — only variety.

Architecture

The rules live in a pure C# core with no Unity dependency. When the player drops a piece, the core resolves the entire turn up front — every clear, jump, push and chain — and returns an ordered list of events. The presentation layer only plays that list back.

That split gives three things I wanted from the start:

  1. A truthful preview. The drag preview calls the exact same simulation as the real move, so what the player sees before releasing is what will actually happen.
  2. Determinism. The same seed and the same moves always produce the same board and the same score, which makes bugs reproducible and saves trivially valid.
  3. Testability. The core is covered by EditMode tests: rule invariants checked over long randomised soak runs, acceptance tests, and parity tests against the original prototype’s recorded output.

Tuning values — spring counts, piece weights, floor targets, perk strengths — live in data assets rather than in code, so balancing never means touching the rules.

Design Process

The game started as a quick web prototype. That is where the rules were found, played and measured, and its numbers came from bots rather than guesses. Two examples:

  • The first version of the spring only dropped a block somewhere. Adding the push cut wasted bounces — jumps that did nothing — from roughly 46% to 24%.
  • Weighting the full 37-shape piece catalogue equally made runs far too short, so the piece pool is weighted by size group and tuned until a typical session landed at around eight minutes.

The Unity version was a faithful port of those rules, verified against the prototype’s output rather than rewritten from memory. For the Roguelike mode I built a simulation harness with several bot strategies to set floor targets and to find perks that were dominant or did nothing — which is exactly the question the beta is now testing with real players.

Where It Is Now

  • Beta on iPhone, with Android builds running from the same project
  • Both modes are playable end to end, with tutorials, saving, haptics, sound and Turkish/English localisation
  • An in-game Report a problem form sends bug, balance and idea reports — with a screenshot, recent logs and the build number — straight to me
  • Art and audio are still partly placeholder, and the Roguelike perk catalogue is only partly in: the MVP ships a core set of perks, with the rest of the designed catalogue, boss floors and floor modifiers planned after the beta

The game is still in active development. What changes next depends on what the beta reports say.