01 / First light
Level 01
Find your rhythm
Follow the arrowhead. Tap a clear path to let it go.
Progress saved on this device
Scope: Analysis of Easybrain’s public Google Play listing and the four screenshots you supplied. This is not an installed-app audit: ad frequency, paywall prices, precise animation behavior, and every settings option have not been verified. Arrowfield is an original browser prototype, not a Kotlin APK.
This version adds layered, beveled arrow paths; a raised board with soft lighting; Mint, Lilac and Peach palettes; subtle mouse parallax; tap ripples and particles; blocked-move feedback; a consecutive-clear flow indicator without a timer; and animated completion confetti. These are lightweight 2.5D SVG/CSS effects rather than a WebGL 3D scene. Depth and particles can be disabled separately. Reduced motion turns off decorative movement. Existing puzzle rules and saved progress are preserved.
The listing describes single-player arrow-removal puzzles, limited lives for blocked taps, hints, untimed play, hundreds of handcrafted levels, daily challenges and monthly trophies. It labels the game offline and lists ads and in-app purchases. A tournament event is also visible. One displayed reviewer requests cloud saves; that is a user report, not proof of the current implementation. Source: Google Play listing.
| Visible element | Design implication |
|---|---|
| Bent, navy arrow paths | The visual challenge comes from tracing direction and dependencies, not fast reactions. |
| Three hearts | Mistakes carry a cost. A separate relaxed mode would serve players who dislike that pressure. |
| Normal / Hard labels | Difficulty should be communicated before a player commits. |
| Arrow counter | Likely a remaining-arrow count, although a static promotional image cannot prove how it updates. |
| Blue highlighted arrow, hint badge | Hints need to identify one useful move without visually overwhelming the board. |
| Dots and a # button | Likely a grid/guide control; its exact behavior is not confirmed. |
| Heart-shaped dense board | Silhouette compositions can provide variety, but small arrows increase selection difficulty. |
| Magnified circular callout | This may be promotional artwork. It does not establish that the installed game has interactive zoom. |
The loop is scan → trace → choose → release → reveal. Every removal reduces visual clutter and unlocks new possibilities. The board itself communicates progress. A useful puzzle has a small but discoverable set of starting moves, dependency chains, and changing regions of interest.
Difficulty is not simply arrow count. Measure the fraction of initially removable arrows, dependency-chain depth, number of bends, crowding, and how far players must visually trace each exit. A large board with many obvious exits may be easier than a small, tightly linked board.
Positioning: A tactile logic game with clear feedback and no rush. The proposed identity uses warm paper, forest ink, soft lime accents, rounded paths, restrained sound, and generous spacing. It intentionally avoids reusing the reference’s artwork, level layouts, name, or promotional compositions.
| Improvement | Player benefit |
|---|---|
| Journey + Zen | Optional three-mistake challenge; unlimited attempts for relaxed exploration. |
| Explain the blocker | A dashed ray and a contrasting blocker turn a wrong tap into a useful lesson. |
| Free hints + undo | Players can learn without spending currency. Undo restores the last release, not spent lives. |
| Readable touch targets | Tap the path body, not just the arrowhead. For a native release, add zoom and ambiguity handling on crowded boards. |
| Honest persistence | Resume the exact puzzle. Later add export/import or optional cloud sync with explicit status. |
| Accessible presentation | Dark palette, reduced motion, optional audio, and directional geometry independent of color. |
Prototype limits: These are precomputed generated boards with geometric silhouette masks, not handcrafted illustrations. There is no account sync, ad SDK, purchase flow, tournament backend, or installable PWA manifest/service worker. Local achievements and a daily completion calendar are implemented in the mobile shell. The daily board uses the device’s UTC date and does not have a competitive leaderboard. Local saving can be blocked or cleared by the browser. The mobile shell keeps one unfinished board per mode and resumes each independently. All 240 levels are unlocked for testing. “Better” is a product hypothesis to validate with players.
Represent each arrow as an ordered list of contiguous integer grid cells from tail to head. Direction is the vector from the penultimate cell to the head. For a proposed release, scan from one cell ahead of the head to the board boundary. If any cell belongs to another arrow, reject the move and return the first blocker. Otherwise commit the release and animate the path out.
This prototype uses snake-like path following, not a rigid-body slide. That choice makes a head-ray test consistent with the animation. If you choose rigid translation instead, you must test the swept area of the entire polyline; a head-only ray would be incorrect.
Store occupied cells in a board lookup. Build a dependency graph with an edge from arrow A to each arrow obstructing A’s exit ray. Removing an arrow can only remove constraints, so a legal move never creates a new deadlock under these rules. Hints should select a currently unblocked arrow, preferably one whose removal unlocks the most other arrows.
The challenge pack starts with an occupied silhouette and peels off winding paths whose heads have a clear exit. This removal order is recorded as a solution certificate. Paths do not overlap; isolated leftover cells become empty space. Candidates are ranked by blocker relationships and dependency depth, then embedded as a stable pack. Every board is checked against its full solution before shipping.
For production, generate a large candidate pool offline, solve every board, compute difficulty metrics, then curate the best boards. Keep a versioned JSON level manifest and solution certificates. Add silhouette masks only after the rectangle engine is stable. Never equate “solvable” with “fun”: remove repetitive boards and excessive single-choice sequences through playtesting.
Required checks: no duplicate occupied cells; all steps orthogonal and adjacent; head direction valid; no self-exit blockage; full solution exists; no save corruption after interruption; hints always legal; last arrow completes exactly once; restart recreates the board; UI locks during animation; undo restores occupancy accurately.
Recommended design: Kotlin with Compose for screens and a custom Canvas board. Compose supports custom drawing through Canvas/DrawScope; see Android’s graphics documentation. Keep game rules independent from rendering so they can run in ordinary JVM tests.
| Layer | Responsibility |
|---|---|
| Pure Kotlin engine | Cell, Arrow, Board, move validation, blocker lookup, solver, undo commands, difficulty metrics. |
| Game state holder | Immutable UI state, events, active level, lives, hints and animation phase. A ViewModel is appropriate for screen-level state; see official guidance. |
| Canvas renderer | Paths, heads, dots, hit testing, exit animation and coordinate conversion. Avoid rebuilding static paths every frame. |
| Persistence repository | Save committed game state and preferences locally. Design a schema version and migration path; persist before relying on animation completion. |
| Level repository | Bundled curated JSON, level versions, seeds and optional future content packs. |
| Platform services | Optional sound/haptics, accessibility semantics, billing and optional cloud backup kept outside game logic. |
Handle process death, background/resume, rotation, interruption mid-animation, and undo after restoring a session. Native Canvas paths need explicit accessibility semantics; they do not automatically become individually accessible controls. Test crowded boards on a small, low-memory Android device.
MVP: short interactive tutorial → continue/new game → board → completion → next level. Include a level collection, Journey/Zen choice, daily board, settings and exact resume. The tutorial should start with two arrows: one visibly blocked, one free. Teach by interaction instead of showing a wall of text.
Next release: curated silhouette collections, two-finger zoom/pan, improved contextual hints, daily calendar, offline progress export/import, more accessible board controls, and a compact statistics screen.
Later experiments: optional challenge packs, weekly local goals, an editor with automatic validation, and opt-in cross-device backup. Avoid gates, keys, moving obstacles and timed modes until you have evidence that players want extra complexity.
Group curated boards into short collections with a distinct visual motif. Use stars for mastery, never to block casual progress. This prototype awards three stars minus mistakes and a one-star penalty if hints were used, with a minimum of one for completion. Journey and Zen scores are separate. Production scoring should label assisted play clearly and avoid punishing accessibility settings.
Give players a natural stopping point after a few boards. Daily rewards should celebrate completion without making a missed day feel like a loss. Do not add a leaderboard unless you are prepared to handle trusted scores, clock manipulation and offline reconciliation.
Suggested commercial model: a useful free game, optional paid original level collections or cosmetic palettes, and a clearly described one-time purchase if you introduce ads. If testing advertising, keep it out of the active puzzle and never cover controls. Rewarded hints should not become the only way to learn. These are proposed product choices, not claims about the reference app’s ad behavior.
Test with players on real phones. Observe mis-taps, whether a blocked move is understood, how often hints are needed, puzzle completion, session length, and the point where boards stop being pleasant to read. Ask players to explain the movement rule in their own words. First optimize clarity and puzzle quality; extra modes cannot compensate for confusing collision rules.
Deliverable: This file is both a playable design specification and an initial product report. Give it to Codex or Claude Code as a behavioral reference for a native Kotlin implementation; the HTML itself is not native Android source.