The Fish is the Track
Building Rapala Fishing: World Tour from a Single Analogy
The Problem
When I joined the project as solo game designer for early pre-production, the core gameplay hadn't been settled. Several proposals had already been prototyped and tested. User testing kept pointing to the same gap: players didn't feel like they were fighting the fish. The challenge felt thin, shallow, moving in the opposite direction of what the Rapala brand was famous for. There was action on screen, but no tension — not the kind you feel in your hands.
I benchmarked the market — playing fishing games across mobile, console, and PC — looking for what the genre was and wasn't doing. I then applied Rational Game Design methodology to map the difficulty problem: where exactly was the player's agency breaking down, and what mechanical levers were missing. The answer pointed to input depth. Players had no way to express skill in the moment-to-moment fight with the fish.
The Insight
The realization came from an unexpected direction: fishing and racing share the same input logic.
One hand steers — that's your rod, moving on X and Y axes to track the fish. The other hand controls speed and resistance — that's your reel, pulling or releasing. The fish isn't just an obstacle, or an enemy. It's the actual goal, like in a racing game, the goal is to complete first. The fish is the track. It's an expression of what you navigate.
That single reframe changed how I thought about every system in the game.
On A/B Testing Sea Gods
Even though I was confident with the mechanic I've proposed, the Product Lead had other ideas and the publisher decided to test both out, and check comparison and approvals.
Two competing designs went into UserBob A/B prototype testing with a US audience — the target market for the game — roughly 100–200 players, tested two to three months before the first soft launch batch. Both designs were shown in randomized order. The Product Lead's proposal, Neptune, and mine, which I called Poseidon. Poseidon achieved 60% approval when shown second, and 87% when shown first.
87% approval from a US audience, for a mechanic that was more arcade and more demanding than anything else in the genre. The first-impression advantage was significant: players who encountered the mechanic cold responded to it immediately, without context or instruction.
The decision was contested. The Product Lead believed his design was stronger, and the sample size left room for that argument. What resolved it was the publisher reviewing the data directly. The numbers were the argument — not the design rationale, not playtester feedback, the numbers. The dual-input mechanic became the foundation.
Image from Google Play. It depicts the Lure phase and the underwater view.
The Risk the Mechanic Carried
A higher-skill mechanic has a higher entry barrier. That was always the real concern — not whether the mechanic was good, but whether players would reach the point where they could feel that it was good.
In mobile, this has compounding effects. A more complex core loop means a harder onboarding problem, which means higher CPI (cost-per-install) and more pressure on the FTUE to carry players through a steeper learning curve. Compared to the competition, the game sat closer to arcade than casual — which was the right call for depth, but not the obvious call for a mobile fishing game in a genre that trends toward simplicity. The publisher was also exploring a Nintendo Switch port at this stage, which reinforced the appetite for a more arcade-leaning design. That port never shipped while I was at the company, but the direction it pointed was consistent with where the mechanic was already going.
Without intervention, the entry barrier would have translated directly into higher early drop-off and increased acquisition cost. My position was that the right response wasn't simplification — it was a better entry path. If the mechanic was solid, it could be taught. The solution was controlled early sessions: not forced wins, but scripted challenges that shaped what players encountered before they were left to play freely. The first sessions weren't supposed to test the player — they were supposed to show the mechanic at its best before asking anything difficult of them. The mechanic was dependent on a strong onboarding layer to reach the player. Without it, the depth wasn't accessible — it was just complexity.
That conviction became the foundation for how the FTUE was eventually redesigned.
What Skill Actually Looks Like
Skill in the Reel Phase works on three layers simultaneously. The first is preparation: a skilled player selects gear tuned to the specific fishing spot, reducing resistance before the fight starts. The second is tracking: keeping the rod indicator centered on the fish's movement — precise enough that the game registered it as a combo state, surfacing a visual indicator that the mechanic supported. The reward layer for that combo didn't make it to ship. The third is tension management: timing press and release on the reel so tension stays in the middle band — enough to pull the fish in, not enough to snap the line.
A player who does all three is playing a fundamentally different game than one who doesn't. That skill gradient was legible — players who mastered the layers progressed faster and engaged more deeply with the system. The mechanic supported that gap from day one.
Building the Gear System from the Same Logic
or: If the fish is the track and the player controls as a driver, the gear is the car
The dual-input mechanic didn't just define how fishing felt — it generated the gear system.
I started from the mechanic itself and asked: what forces are actually in play during a fight? The fish exerts force on the X and Y axes, pushing the on-screen indicator away from where the player wants it. So the rod needed to counteract that. The fish has weight pulling against the line. So the line needed a weight capacity that determines how much stress it can absorb before snapping. The reel controlled how fast the player could pull, and how quickly the system recovered between bursts.
From this, four player-facing attributes emerged — all of them derived from gear, none from the player character:
Grip — governs how much the fish's movement affects the on-screen indicator. High Grip means the player moves the indicator with less resistance, tracking the fish more precisely even when it fights back hard.
Strength — determines how much tension the line absorbs per unit of time. A higher Strength means the same aggressive reel won't spike tension as fast, giving the player more room to push.
Recovery — controls how quickly tension bleeds off when the player eases up. High Recovery means a brief pause doesn't cost much distance — the line stabilizes faster, and the player can breathe without losing the fish.
Speed — the rate at which the player reels the fish in. Higher Speed closes distance faster, but paired with low Strength, it also builds tension faster.
Players themselves have no attributes. Like a driver in a racing game, the character exists only for self-expression. All gameplay values come exclusively from the gear.
The equipment roster was also shaped by a product constraint: Rapala, the IP owner, is primarily a lure brand. Lures needed to be prominent in the game. Rather than treating this as a feature request bolted onto the system, I integrated it into the architecture — lures became a distinct gear category with their own mechanical role in the Lure Phase, separate from the rod, reel, and line that governed the Reel Phase.
The constraint became part of the design.
This wasn't an aesthetic choice — it was structural. If player attributes existed independently of gear, collecting gear would become optional. By making gear the exclusive source of all gameplay values, every new piece of equipment directly changed how the game felt. Each upgrade was an experience upgrade before it was a numbers upgrade — closer in feel to how gear works in arcade and platform games than to the numerical scaling common in mobile F2P. Collecting became mechanically meaningful, not just cosmetic.
Image from Google Play. It depicts the 3 Gear elements for fighting the fish, and also a collection of Lures.
Building the Session Loop
or: using the real world concept of a Fishing Trip to create a session
The mechanic and gear defined the moment-to-moment fight. The session structure came from a different starting point: how does fishing actually work?
You don't show up at a lake and cast randomly. You plan a trip. You choose where to go, when to go, what to bring. That real-world logic became the unit of play: the Fishing Trip. A system that would account for when rewards happened, how many fishes should be caught in a cycle to keep Session Lengths within scope, and a defined unit of challenge/central fantasy that could bolster interaction and serve as a balancing tool, as in to answer questions I asked but left the project before they were fully answered (such as "how hard should a Fishing Trip be to feel fulfilling?")
When I moved into the Lead Designer (de facto Game Director) role, I mapped the game's systems against three player motivations — not as a retroactive justification, but as a design tool for what still needed to be built:
Planning & Decision Making — the feeling that preparation made a difference
Collectionism & Completionism — the drive to own, build, and fill out the roster
Discovery & Novelty — the pull of what's next, just out of reach
Those motivations defined the shape of the planning layer. A player choosing a destination needed to know what they were committing to — what fish lived there, what conditions affected them, what gear would give them an edge. The information the game surfaces before a trip isn't decoration: it's the decision space that makes planning feel like it matters. And it also accounted for a layer of monetization — because this is mobile gaming after all — where all circumstances regarding time of day and weather were random, unless you booked the trip with a premium currency, simulating booking a quality hotel versus going unprepared.
Each layer feeds the next. New locations hold fish that require better gear to catch. Better gear requires progression. Progression requires playing. Playing requires planning. The loop closes on itself.
Image from Google Play. Depicts the selection of locations in the game.
When the Mechanic was Challenged
Over a year after the first soft launch, when Reliance acquired the game, the dual-input mechanic came under pressure. The concern was complexity — that the two-input system was too demanding for new players and would cause early drop-off.
The A/B data from the original prototype tests was the argument that kept the core intact. Simplifying the mechanic would have collapsed the skill layer everything else depended on. What changed was the entry path: a simplified mode reduced input demands for players who needed it, while the full mechanic remained available as an opt-in with a higher reward multiplier. The mechanic wasn't simplified — it was preserved behind a mode split that gave new players a way in. The FTUE case study covers that design in detail.
What Shipped
The first soft launch batch shipped with core gameplay and no complete session loop. With no progression or metagame in place, retention was driven entirely by the mechanic itself. D1 came in at 20%, against an internal benchmark of 5–7% for mobile fishing games at the same stage. The mechanic could carry the game.
The second batch added the fishing trip loop — the planning layer, the destination information, the gear selection before committing to a session. D3 retention moved from under 5% to around 10%. The loop was working, even before it was fully tuned.
The architecture held through both batches without structural revision. The gear system supported dual-axis item progression across the full content lifecycle: level-based power scaling for moment-to-moment growth, rarity-based power ceiling tied to monetization. The quest framework built in parallel scaled to 600+ active tasks in production. Every system traced back to the same foundation — the same forces the mechanic put in the player's hands on day one.
The validation wasn't just that the mechanic performed — it was that everything built on top of it held. Gear, session structure, progression, quest content: all derived from the same underlying logic. Because the foundation didn't move, the rest of the game could scale without coming back to redesign the core interaction.
The fish is the track. That one idea held the whole thing together.
Rapala Fishing (formerly: Rapala Fishing: World Tour) — Lead Game Designer [de facto Game Director] (Oktagon/Fortis Games) · 2021–2023