From Prototypes to Product: Designing Lucky Clash's Core Gameplay

At From Beyond Game Studio, I needed to define a promising core gameplay direction for a mobile free-to-play game with the resources of a small independent team. That required more than finding a concept that looked interesting on paper. The game needed intuitive interactions, strategic depth, short and repeatable battles, room for PvP and PvE progression, and a production structure we could expand efficiently.

Rather than immediately committing to our initial idea, I explored multiple concepts through HTML5 prototypes and player tests. The objective was to identify which combination of mechanics could support both engaging gameplay and a viable long-term product.

The experiments began with a traditional tower defense core: players summoned random creatures to defend a base, merged three identical units, and used a preparation phase before combat. Enemies moved toward the base but did not directly fight the allied units.

I then explored alternative structures across 11 documented configurations, grouped into five gameplay approaches:

Defend the Base (#0, #6). Test a random-summoning tower defense with and without a preparation phase. The original #0 used a building phase; #6 removed it.

Direct Unit Combat (#1–#3). Explore situations where allied creatures and enemies fight one another. Variants introduced restricted melee/ranged placement, changes to battle pacing, and automatic merging of two identical units.

Free Placement & Card Selection (#4, #5). Remove fixed melee/ranged tile restrictions, then explore a rotating card hand as an alternative to unrestricted summoning.

Inventory-Based Battles (XX, #7). Experiment with a 4×6 grid and creatures occupying different amounts of space. One variant used PvE encounters; the next introduced a PvP-style presentation.

Squad-Based Battles (#8, #9). Test a format where players freely choose creatures while available team slots expand as waves progress. Both PvE and experimental PvP-style encounters were explored.

These prototypes were not a simple sequence of cosmetic changes. They tested different relationships between player agency, randomness, positioning, resource management, encounter pacing, and competitive framing.

All prototypes were built for the browser in HTML5 and tested on Poki, with 500 players per test run. The supplied tracking workbook records 24 distinct quantitative runs across eight configurations, while the wider exploration also included variants without equivalent records in that file. Several configurations were tested multiple times, and the results below use their average per-run metrics.

Before scheduling tests, I evaluated Poki traffic periods and selected dates and times intended to reduce distribution variability. The builds remained close to 45 MB across variants—well above the lightweight size recommended for the platform at the time. That likely introduced loading friction into absolute engagement measures, though broadly consistent build sizes made relative comparisons more useful.

I treated Poki as an early gameplay-validation environment, not as a source of native-mobile retention benchmarks. Poki uses an average playtime of roughly three minutes as an important player-fit reference; browser playtime should not be interpreted as equivalent to Android session length or D1 retention.

Poki supplied limited numerical reports, but it also provided recordings of real players with visible click locations. I used those recordings to examine three questions: Could players understand the game? Were they using its systems strategically? Did the experience show signs of friction or continued motivation?

The original tower defense core averaged 1 minute 54 seconds of playtime, with 10.0% of its reported playtime observations reaching five minutes or more.

The direct-combat, free-grid, and card-selection variants generally produced playtime averages between roughly 2 minutes 21 seconds and 2 minutes 53 seconds. Later squad-based experiments showed the strongest recorded engagement signals: the PvE variant (#8) averaged 3 minutes 56 seconds, with 24.9% reaching the 5+ minute band; the PvP-style variant (#9) averaged 4 minutes 15 seconds, with 23.7% in that band.

Both squad-based configurations exceeded the three-minute average-playtime reference relevant to Poki. The broader differences were encouraging, but these were exploratory tests with changes to multiple mechanics, so the results should not be interpreted as isolated causal effects of individual features.

The recordings explained important issues that playtime alone could not capture.

Unclear random summoning (#0). Players often struggled to understand the random-summon system and did not realize creatures could be repositioned after summoning. This suggested that an apparently simple mechanic could still obscure player control.

Unintuitive placement restrictions (#1–#3). Players repeatedly tried to place ranged units on melee-only tiles and vice versa. The restriction created unsuccessful interactions that conflicted with what players expected the interface to allow. I favored free positioning, letting strategic depth come from creature abilities, roles, and spatial constraints rather than invalid tiles.

Combat pressure without a preparation phase. In real-time deployment variants, stronger enemies often prompted hurried, seemingly unplanned summons. This supported keeping a dedicated building phase so players could assess options and organize their teams before combat.

Harsh defeat consequences. In earlier non-squad-based formats, losing a stage meant restarting from the beginning; recordings suggested many players stopped after losing. The squad-based approach allowed a more forgiving player-health structure, in which individual losses could trigger a chance to recover rather than immediate full-stage reset. That direction informed Lucky Clash's lives and comeback systems.

These observations were qualitative, not a quantified click-error or frustration score. Repeated clicks or brief inactivity could have more than one explanation, so I interpreted them in the context of the gameplay on screen.

I did not choose the direction solely by ranking playtime. I also evaluated how well each mechanic fit a mobile screen, the number and clarity of UI actions, the pace of player input, potential strategic depth, ease of iteration, content-production costs, marketing readability, monetization opportunities, and compatibility with a long-term meta layer.

The goal was to select a system that offered meaningful decisions without requiring unnecessary interactions—and one that our team could realistically expand.

The most promising core was not necessarily the one with the single highest metric.

The resulting Lucky Clash core combines mechanics explored across several prototypes; it is not a copy of the single highest-playtime build.

Before a match, the player builds a deck of five creatures from their unlocked collection. During preparation, they receive a random hand of three summon cards drawn only from that deck, with duplicates possible and up to three rerolls per wave. Each creature has its own summoning cost, so players must weigh their options against limited currency.

Between waves, players receive a fixed currency reward and an additional bonus after a loss. They may sell deployed creatures for less than their original cost to change their strategy. Combat uses a dedicated building phase, direct creature-versus-creature encounters, merging, and flexible grid positioning for creatures of different sizes. A player-health system and comeback mechanics reduce the penalty of individual losses. Competitive encounters are supported through the game's subsequent asynchronous PvP system.

This design combines pre-match strategy, controlled randomness, meaningful economic trade-offs, spatial team-building, and opportunities for recovery—while remaining compatible with further PvP, PvE, collection, and village progression.

The most useful prototype was not necessarily the one with a single highest metric. Quantitative data showed which directions deserved attention; recorded player behavior explained where players struggled or found meaningful choices; and product constraints determined what we could sustainably build.

The process taught me to evaluate gameplay as an interconnected system and to make deliberate trade-offs between engagement, accessibility, strategic depth, and production feasibility. That evidence-informed approach shaped Lucky Clash's selected core and created a stronger foundation for subsequent native mobile development and testing.