Phase 7.1 Playtest Findings: Hi Fi Snake build023.zip

Executive Summary

The playtest for Hi Fi Snake (build023.zip) conducted between July 12th and July 20th demonstrated that while average playtime has slightly improved (rising from 1:06 to 1:31 according to developer metrics), first-session onboarding remains the primary bottleneck for player retention. A significant portion of players failed to build a basic mental model of the game, often moving straight forward without collecting pellets, ignoring lateral movement entirely, and quickly colliding with hazards. The opening sequence currently tests movement and navigation before teaching them, and the initial tutorial popup fails to effectively communicate the core loop.

Current Game State

Based on the current game-state GDD, the tested build features:

* Grid-Based Movement: A runner/collector loop where players navigate a grid to collect pieces, grow a tail, and unlock doors.

* Active-Input Player Movement: The player character only moves while input is actively held (joystick or keyboard) and stops immediately upon release.

* Player Speed Progression: Speed starts at 4 in Room 1 and increases by 0.4 per room up to a cap of 12.

* Runtime Control Hint Selection: The game dynamically switches UI hints based on the resolved device form factor (mobile vs. desktop).

Developer Context

According to the Developer Notes, the primary focus of this playtest was evaluating first-session onboarding and early-game progression. The developer noted that:

* Average playtime improved to 1:31, but players still struggle to understand the core interaction before dying.

* The first rooms allow straight movement before suddenly requiring lateral movement, testing mechanics rather than teaching them.

* The opening tutorial popup is poorly timed, explaining mechanics before players experience them, and is difficult to read/dismiss in portrait mode.

* Early missions (e.g., "Collect 100 pellets") feel unattainable given that first runs typically yield only 3–5 pellets.

Positive Signals

* Slightly Improved Playtime & Progression Capability

Confidence*: Medium

Evidence*: Developer notes indicate average playtime increased to 1:31. A few players successfully navigated multiple gates (e.g., a Vietnam player passed 4 gates and collected a yellow octahedron over a 02:44 session; an Indonesia player quickly understood controls and passed 2 gates in 24 seconds).

Negative Signals

* Failure to Build a Mental Model (Straight-Line Syndrome)

Confidence*: High

Evidence*: Multiple playtest sessions showed players moving exclusively straight forward, ignoring pellets, and immediately dying. For example, a Peru player "only went straight forward" and a USA player "went ahead without collecting anything... didn't move right or left" across two consecutive runs.

* Early Deaths to Red Barriers

Confidence*: High

Evidence*: Players frequently collided with the red barriers or walking hazards immediately after passing the first gate (e.g., Venezuela, Indonesia, USA, and Vietnam sessions all ended due to red barrier collisions shortly after the first gate).

* Technical Freezes and Inactivity

Confidence*: Medium

Evidence*: An India player on a mobile tablet started the run but "never moved" (01:02 session). Another India player on mobile stopped moving after the first gate, with the observer noting "the image bugged, I believe the player just closed the game."

Confusion And Friction

* Tutorial Popup Obstruction and Dismissal Friction

Confidence*: High

Evidence*: The Peru player took 26 seconds just to dismiss the "how to play" popup. Developer notes confirm that players often miss the "OK" button and that the popup explains mechanics before players have experienced movement, collection, or doors.

* Lack of Lateral Movement Comprehension

Confidence*: High

Evidence*: Players in Peru and the USA did not attempt to turn left or right, suggesting they did not understand that lateral movement was possible or necessary to collect pellets and avoid obstacles.

* Discouraging Early Mission Goals

Confidence*: Medium

Evidence*: Developer notes highlight that showing long-term missions like "Collect 100 pellets" or "Walk 100 km" immediately after a player dies with only 3–5 pellets makes progression feel unattainable.

Retention And Replayability Signals

* High Early Churn Risk

Confidence*: High

Evidence*: The majority of playtest sessions lasted less than 1 minute (e.g., Indonesia at 00:27 and 00:43, India at 00:33, Peru at 00:49). Players frequently quit after a single run (6 out of 10 recorded sessions had only 1 play) due to immediate confusion or early deaths.

Device / Browser / WebGL Concerns

* Tablet Inactivity: The only tablet player in the dataset (India, Mali-G57 GPU) never moved, which may indicate that tablet device resolution issues or control mapping bugs persist.

* Portrait Mode UI Constraints: Developer notes indicate that in portrait mode, the tutorial popup often blocks the player's view of the referenced door, causing spatial confusion.

Current Design Vs Observed Response

* Design Intent: Active-input movement is designed to provide intentional, player-driven movement and cleaner pacing.

* Observed Response: Players frequently stopped moving entirely when faced with hazards (e.g., India player "stopped walking" and was hit by a red barrier; Vietnam player "went too slow" and was hit), suggesting that active-input movement may feel too demanding or confusing for players expecting auto-walk mechanics.

* Design Intent: Gradual speed progression starting at 4 is meant to soften early difficulty.

* Observed Response: Players still died almost immediately in Room 1 or 2, not because of excessive speed, but because they did not understand the basic requirement to steer and collect pellets.

Missing Or Incomplete Systems Affecting Results

* Interactive Tutorial/Onboarding Level: The game currently lacks a safe, hazard-free introductory space to teach turning and pellet collection before introducing red barriers and walls.

* Forgiving Tutorial UI: The current tutorial popup cannot be dismissed by tapping anywhere, creating a click-blocker for players who miss the "OK" button.

Confidence By Finding

Finding	Confidence	Why
Players fail to build a mental model (ignore pellets/lateral movement)	High	Observed across multiple sessions (Peru, USA) and explicitly highlighted in Developer Notes.
High early churn and short session lengths	High	Quantitative data shows 60% of players quit after 1 run, with most sessions lasting under 60 seconds.
Tutorial popup causes friction and is hard to dismiss	High	Peru player took 26s to dismiss it; developer notes confirm poor timing and layout issues in portrait mode.
Early deaths to red barriers	High	Multiple sessions ended in immediate collisions with red barriers right after the first gate.
Tablet player inactivity	Medium	Only one tablet session was recorded, and the player did not move, suggesting potential control detection issues.
Active-input movement causes players to freeze under pressure	Medium	Observed in India and Vietnam sessions where players stopped moving or went too slow and were hit by hazards.

Data Quality Caveats

This playtest batch consists of a small sample size (10 sessions) primarily focused on mobile devices in portrait orientation. Because the vast majority of players churned in Room 1 or Room 2, there is virtually no data to evaluate late-game balance, speed scaling, or the procedural room selection system.

Phase 7.2 Next-Step Proposal: Hi Fi Snake build023.zip

Proposal Summary

The primary focus of the next build cycle must be overhauling the first-session onboarding experience. Playtest data shows that players fail to build a basic mental model of the game, often moving straight forward without collecting pellets or turning, leading to rapid deaths from hazards. We must rebuild the first three rooms to teach mechanics progressively without early punishment, redesign the intrusive tutorial popup flow, and replace discouraging long-term missions with immediate, achievable goals.

Urgent

* Rebuild the First Three Rooms (Level Design Onboarding): Replace the current punishing start with a progressive sequence. Room 1 must be a safe, hazard-free space where pellet placement forces lateral movement. Room 2 should introduce simple walls to teach turning. Room 3 should introduce hazards (lava/fire) only after movement is understood. (Evidence Class: evidence_backed; Source Finding: Players fail to build a mental model / Early deaths to red barriers)

* Review first-room pellet placement: Position pellets so players must intentionally perform multiple left/right turns before reaching the first door. Avoid allowing the first door to be reached primarily through forward movement.

* Redesign Tutorial Flow & Dismissal: Remove the opening popup that explains mechanics before players experience them. Instead, show contextual hints (e.g., "Collect pellets to open doors") only after the first door unlocks. Ensure all tutorial popups can be dismissed by tapping anywhere on the screen. (Evidence Class: evidence_backed; Source Finding: Tutorial popup causes friction and is hard to dismiss)

* Teach One Concept Per Room: The opening sequence should introduce only one new mechanic at a time (movement → navigation → hazards). Avoid combining multiple new concepts in the same room.

Next

* Improve First Reward Loop & Delay Long-Term Missions: Replace discouraging early missions (e.g., "Collect 100 pellets") with an immediate, highly achievable goal (e.g., "Collect 3 pellets to unlock first skin") to give players an early feeling of success. (Evidence Class: likely; Source Finding: Discouraging early mission goals / High early churn risk)

* Refine Active-Input Movement Feedback: Provide clearer visual or audio feedback when players stop moving or freeze under pressure to help them understand that active input is required to navigate hazards. (Evidence Class: likely; Source Finding: Active-input movement causes players to freeze under pressure)

Later

* Late-Game Balancing & Procedural Room Selection: Defer adjustments to late-game pacing, room randomization, and speed scaling. (Reason: Players are currently churning in Room 1 or 2, so we lack sufficient data to evaluate these systems.)

* Cosmetic Pricing & Mission Economy: Defer broad economy rebalancing until first-session retention is stabilized. (Reason: Focus must remain on the first 2 minutes of gameplay.)

Keep

* Active-Input Player Movement: Retain the active-input control model as it provides intentional player-driven movement, but soften the early-game environment to prevent panic freezes.

* Player Speed Progression Formula: Keep the build023 starting speed at 2.4 and room scaling at 0.55. Keep current movement pacing for now. The playtest does not provide sufficient evidence that speed progression is responsible for early churn.

Try

* Contextual Control Prompts: If a player remains stationary in Room 1 for more than 3 seconds, display a subtle, non-blocking directional arrow overlay on the grid to prompt movement.

Avoid / Defer

* Avoid early hazard placement: Avoid introducing mechanics before they have been taught. For instance, do not place red barriers or walking hazards in the immediate path of the first gate. (Evidence Class: evidence_backed; Source Finding: Early deaths to red barriers)

* Defer shop expansion: Avoid adding more cosmetic items or complex menus until the basic onboarding flow is validated. (Evidence Class: likely; Source Finding: High early churn risk)

Reference Trinity Impact

Reference Role	Impact	Explanation
Primary	strengthened	Teaching players how to turn and collect pellets safely builds the foundational mental model required for Snake's self-growing obstacle mechanic.
Secondary	unchanged	The room-by-room progression and upgrade cadence inspired by Archero remain intact, though early room layouts are simplified for onboarding.
Tertiary	unchanged	Neon spectacle and visual feedback remain, but visual clutter is minimized during the tutorial phase to ensure readability.

Evidence Classification

Proposed Change	Evidence Class	Supporting Evidence
Rebuild first three rooms	evidence_backed	Multiple players failed to turn or collect pellets, dying immediately to red barriers right after the first gate.
Redesign tutorial popup flow	evidence_backed	Peru player took 26s to dismiss the popup; developer notes confirm poor timing and layout issues in portrait mode.
Delay long-term missions	likely	Developer notes highlight that showing 100-pellet goals immediately after a player dies with 3-5 pellets feels discouraging.

Root Causes

* Gameplay Teaches Through Failure Instead of Success: The game immediately tests lateral movement and hazard avoidance before teaching basic grid navigation.

* Intrusive & Poorly Timed UI: The opening tutorial popup blocks gameplay, explains mechanics out of context, and is physically difficult to dismiss on mobile.

* Mismatched Progression Milestones: Showing long-term grind missions to players who survive for less than 30 seconds creates a feeling of futility.

Production Risk

* Onboarding Level Maintenance: Creating bespoke tutorial rooms (Rooms 1-3) requires manual level design and bypasses the procedural generation system for the start of the run.

* UI Layout Fragmentation: Ensuring the tutorial hints and popups scale correctly across both portrait mobile and landscape desktop.

Next Test Hypotheses

* Hypothesis 1: Introducing a hazard-free Room 1 that forces lateral movement to collect pellets will eliminate "Straight-Line Syndrome" and increase Room 1 completion rates by 40%.

* Hypothesis 2: Removing the opening popup and allowing tap-anywhere dismissal for contextual hints will reduce onboarding friction and increase the percentage of players completing Room 1 and attempting a second run.

Suggested Version Note

"Onboarding overhaul: Rebuilt the first three rooms into a safe, progressive tutorial sequence, redesigned tutorial popups for easier dismissal, and introduced achievable early-game goals."

What To Watch Next

* Observe if players in Room 1 successfully perform lateral turns to collect pellets.

* Track the average time taken to clear Room 1 and Room 2.

* Monitor if players easily dismiss or interact with the new contextual hints.

Developer Notes

# HiFi Snake: Build 023 Playtest Summary

Date: July 20, 2026
Platform: Poki (Web)

# Executive Summary

The playtest indicates that first-session onboarding is currently the primary retention bottleneck.

Although recent builds improved average playtime (1:06 → 1:31), session videos show many players never understand the game's core interaction before dying. As a result, current data is insufficient to evaluate late-game balance or long-term progression.

#Key Findings
1. Players don't build a mental model

A recurring behavior across multiple sessions was:

Spawn → Move Forward → Ignore Pellets → Die → Quit

Players often failed to understand:

why they should move sideways
why pellets matter
the relationship between doors, hazards and progression

This suggests an onboarding/readability problem rather than simply a control problem.

2. The first rooms test mechanics before teaching them

The current first rooms allow players to move mostly straight before suddenly requiring lateral movement.

Many players:

collect the first pellet automatically
continue straight
miss nearby pellets
collide with the first wall or hazard

The opening sequence is currently testing movement instead of teaching it.

3. Tutorial timing is poor

The first popup explains that pellets open doors before players have experienced:

movement
pellet collection
doors

In portrait mode, the player often cannot even see the referenced door.

Several players also appeared to miss the OK button.

4. Early progression is discouraging

After dying, players are immediately shown missions like:

Collect 100 pellets
Walk 100 km

Most first runs collect only 3–5 pellets, making progression feel unattainable instead of rewarding.

5. Late-game remains unverified

Very few players consistently reach the later rooms.

Late-game pacing, room randomization and speed scaling may still require adjustment, but they are not the current bottleneck.

# Crossy Road Takeaways

Crossy Road teaches almost everything through level design rather than tutorials.

Its opening gradually introduces:

movement
navigation
hazards
increasing difficulty

Each mechanic is learned before the next is introduced.

HiFi Snake should adopt the same philosophy.

# Next Steps
1. Rebuild the first three rooms

Room 1: Safe tutorial room

No hazards
More pellets required
Pellet placement forces left/right movement

Room 2: Navigation

Simple walls
Small maze
Teach turning without heavy punishment

Room 3: Danger

Introduce lava/fire
Introduce pressure only after movement is understood
2. Redesign tutorial flow

Remove the opening popup.

Instead:

Show "Collect pellets to open doors" after the first door unlocks.
Introduce lava/fire only when it first appears.
Allow tutorial popups to dismiss by tapping anywhere.
3. Improve the first reward loop

Give players an immediate achievable goal.

Example:

Collect 3 pellets
Unlock first skin

Delay longer-term missions until after players experience an early success.

4. Re-evaluate after onboarding

Only after players consistently reach the mid-game should we revisit:

room balancing
speed scaling
procedural room selection
mission economy
cosmetic pricing

# Goal of Build 024

The objective is not to increase late-game difficulty or progression depth.

It is to ensure that first-time players understand the game, successfully learn its mechanics, and immediately want to press Play Again after their first death.

Current GDD / Game State

# IcoBitZip / Hi-Fi Snake

Project type: A Unity Game / Unity Project.

# Diary Notes
2026 - July - 15th
Ideation setup is completed
Ideation phase 5 is under `Ideation\hi-fi-snake-game-concept.md`
Ideation phase 6 is under `Ideation\hi-fi-snake-experiment-setup.md`

2026 - July - 16th
This project has started as a clean Vault Retest project, without much changes from the original mobile game but now, after its first playtests we will start the adaptation proceess. Basically `ideation/GAME_CONCEPT.md` starts to become history record instead of actual project design and goals source of truth.

## Game Overview
IcoBitZip is a grid-based runner/collector game where the player advances through rooms, gathers pieces, avoids hazards, and opens doors that require collected pieces.

Core loop:
1. Move the character on a grid.
2. Collect pieces to grow your tail/resource count.
3. Reach doors and spend required pieces to progress.
4. Survive hazards and push distance/progression further.

This project doesn't use MMCore.

## Game Design Notes

### Controls
- Mobile: virtual joystick (OnScreenStick).
- Desktop: keyboard movement (WASD and Arrow Keys).
- Movement intent is consumed through the grid-direction provider path and converted into grid turns.
- `JoystickControls` resolves mobile-vs-desktop at runtime for WebGL UI presentation.

Design intent:
- Controls should feel immediate and readable.
- The player should always understand available input on desktop and mobile.

## Current Codebase Snapshot (Small Assessment)
This project is built on the Manifesto/MMCore-style service architecture and scene/gameplay modules.

Key systems currently visible in code:
- Grid movement and directional turning.
- Room progression + door requirement checks.
- Piece collection and tail consumption.
- Match lifecycle (start, death, game over).
- Platform integration via PlayGama service.

### Current Input State
- Playable and stable with current controls.
- Active production flow is joystick + keyboard through the grid-direction provider architecture.
- Joystick visuals and the mobile hint are now hidden on desktop browser contexts.
- Desktop hint support is optional and can be wired into `JoystickControls.desktopHint` when the UI asset exists.

## Project Plan

### Implemented - Runtime Control Hint Selection
`JoystickControls` now keeps the input popup alive but switches visible UI based on resolved device form factor.

Runtime behavior:
- Mobile/tablet: show joystick visuals and the mobile hint.
- Desktop: hide joystick visuals and the mobile hint, then show the optional desktop hint if assigned.
- Missing hint references are allowed, so the current prefab works before the desktop hint exists.

Device resolution:
- Editor defaults to desktop in `Auto`.
- `JoystickControls.deviceOverride` can force desktop or mobile for editor/development testing.
- WebGL `Auto` uses Playgama device type when available, otherwise falls back to browser checks through `IcoBitZipDevice.jslib`.

Browser fallback signals:
- `navigator.userAgentData.mobile` when available.
- `matchMedia("(pointer: coarse)")`, `matchMedia("(hover: none)")`, and `navigator.maxTouchPoints`.
- User-agent string only as a final fallback.

### Implemented - Player Speed Progression Per Room
To soften early difficulty while keeping escalation, player speed now starts lower and scales when entering new rooms.

Architecture:
- `GridMover` exposes runtime speed (`RuntimeSpeed`) and effective speed (`EffectiveSpeed`) but does not contain progression rules.
- `PlayerSpeedResolver` is responsible for progression logic and applies runtime speed updates to the player mover only.
- Room progression signal source is `IcoBitZipIngameScene.OnNewRoom`.

Current tuning (v1):
- `startSpeed = 4`
- `speedPerRoom = 0.4`
- `maxSpeed = 12`

Rule:
- Room 1 starts at 4.
- Entering room 2 already increases speed.
- Formula: `speed = min(12, 4 + (roomIndex - 1) * 0.4)`.

Design intent:
- Easier onboarding for players struggling in first rooms.
- Predictable progression and easy balancing via 3 variables.
- Hazard speed remains unchanged.

### Next Step - Desktop Hint Asset
Create and wire the desktop control hint:
- Place it under `JoystickControls.prefab` in the existing bottom control band.
- Communicate WASD + Arrow Keys.
- Assign it to `JoystickControls.desktopHint`.
- Ensure `HideOnJoystickMove` also hides the desktop hint after the player moves.

### Following Step - Portal SDK Abstraction + Poki Playtest
Integrate Poki SDK for playtesting while keeping PlayGama support:
- Keep existing PlayGama integration functional.
- Introduce/extend a portal abstraction layer to handle PlayGama, Poki, and future portals.
- Route portal-specific features (ready signal, ads, storage hooks, etc.) through this abstraction.

Target outcome:
- Single gameplay code path with portal-specific adapters.
- Easy switching of portal backend per build target.

### Implemented - Active-Input Player Movement
Player movement mode is now selected through a service prefab in the active `ServiceManager-Services-*` preset.

Current mode:
- `ActiveInputPlayerMovementService` is enabled in the active service preset.
- Player movement only runs while the virtual joystick or keyboard movement action is actively producing input.
- Releasing input stops the player immediately, even mid-cell.
- Robot animation now follows the same active movement state: active movement crossfades to `Running`, standing still crossfades to `Idle`.
- Door opening and death still force movement to stop.
- Grid turn behavior is selected on `GridInput.turnMode`.
	- `PerpendicularAndReverse`: 90-degree turns and 180-degree reversals are allowed.
	- `PerpendicularOnly`: only 90-degree turns are allowed; holding the opposite direction stops movement while held.

Revert/swap option:
- `AutoWalkPlayerMovementService` exists as the previous auto-walk behavior option.
- To restore auto-walk, replace `ActiveInputPlayerMovementService` with `AutoWalkPlayerMovementService` in the active service preset.
- Do not include both movement service prefabs at the same time because both register as `PlayerMovementService`.

Design intent:
- Intentional player-driven movement at all times.
- Cleaner interaction pacing for talk/interaction moments.
- Easy behavior switching without changing player prefab wiring.

## Cheat Sheet (To Expand)
- Reset progress: TBD (document exact persistence keys/flow once mapped).
- Skip flow/testing shortcuts: TBD.
- Portal test switches (PlayGama/Poki): TBD.
- Movement mode:
	- Active input: use `ActiveInputPlayerMovementService` in the active `ServiceManager-Services-*` preset.
	- Auto walk: use `AutoWalkPlayerMovementService` in the active `ServiceManager-Services-*` preset.
	- Only one `PlayerMovementService` prefab should be present in the service preset.
- Turn mode:
	- `GridInput.turnMode = PerpendicularAndReverse`: allows reversing direction.
	- `GridInput.turnMode = PerpendicularOnly`: keeps classic 90-degree turns and stops on opposite input.
- Player speed tuning variables:
	- `startSpeed`: first room speed.
	- `speedPerRoom`: increment applied on each new room.
	- `maxSpeed`: hard cap for late-run speed.
- Control UI testing:
	- `JoystickControls.deviceOverride = Auto`: Editor behaves as desktop; WebGL resolves from portal/browser.
	- `ForceDesktop`: hides mobile joystick visuals and mobile hint.
	- `ForceMobile`: shows mobile joystick visuals and mobile hint.

### Quick Verification Matrix (Portal Builds)

| Mode | Define Symbols (WebGL) | Expected Template | Expected Runtime Behavior | Quick Pass Criteria |
|---|---|---|---|---|
| Playgama | `PLAYGAMA_BUILD;DOTWEEN` | `PROJECT:Bridge` | Playgama bridge initializes; game sends ready message through `PlayGamaService` | Game boots, no missing-service errors, Playgama calls succeed |
| Poki | `POKI_BUILD;DOTWEEN` | `PROJECT:poki-template` | Poki SDK initializes; loading start/finished flow runs | Game boots, no missing-service errors, Poki init completes |
| Clean | `DOTWEEN` | Neutral template (not Poki, not Bridge) | No Poki/Playgama SDK initialization; local persistence fallback is used | Game boots, no SDK init logs/errors, gameplay/save loop works |

Validation rules:
- Never enable `PLAYGAMA_BUILD` and `POKI_BUILD` together.
- `ServiceManager.prefab` currently points to `ServiceManager-Services-Poki.asset`.
- If `PLAYGAMA_BUILD` is enabled, WebGL template must be `PROJECT:Bridge` and `ServiceManager.prefab` should point to `ServiceManager-Services-Playgama.asset`.
- If `POKI_BUILD` is enabled, WebGL template must be `PROJECT:poki-template` and `ServiceManager.prefab` should point to `ServiceManager-Services-Poki.asset`.
- If neither symbol is enabled, use a neutral template and `ServiceManager-Services-Clean.asset`.
- `ServiceManager-Services-Poki.asset` must include `PokiService` and must not include `PlayGamaService`.
- `ServiceManager-Services-Playgama.asset` must include `PlayGamaService` and must not include `PokiService`.
- `ServiceManager-Services-Clean.asset` must not include `PokiService` or `PlayGamaService`.
- `WebPersistenceService` is shared by portal and clean presets; in Playgama builds it syncs through Bridge storage, otherwise it uses local `PlayerPrefs`.
- `PortalAdService` is shared by all presets; it only supports ads in Playgama builds and acts as a no-op fallback elsewhere.

### Local WebGL Test via Python Server (Windows PowerShell)
Use this when testing already exported builds inside builds/.

1. Open PowerShell in the project root.
2. Pick the build folder you want to test (example: build004).
3. Start a local HTTP server from that build folder.

	cd builds/build004
	py -m http.server 8080

If py is not available, use:

	python -m http.server 8080

4. Open the browser at:

	http://localhost:8080

5. Stop the server with Ctrl+C in the same terminal.

Notes:
- Run the server from the specific build folder that contains the exported index.html.
- If one build fails, test another build folder the same way (for example build002, build003, build004).
- If local loading fails due to compression or MIME behavior, generate a Development WebGL build with Decompression Fallback enabled for local verification.

Raw CSV / Spreadsheet Text

Game,When,Version,Country,Duration,Plays,Audience,Device,Orientation,WebGL Renderer,navigator.hardwareConcurrency,navigator.devicePixelRatio,User Agent,Notes,Q1: Session Density & Volume: How many total runs did the player attempt, and what was the exact duration of their longest single run?,Q2: Quantitative Retry Momentum: What was the player's average downtime between a death and hitting "Play Again"?,Q3,Q4: First Avoidable Mistake: When and where did the player first lose control before a death?,Q5: Pre-Death Intent: What was the player doing immediately before they died?,Q6: The Termination Point: What specific event triggered the end of the entire play session?
Hi Fi Snake,26-jul.-17,build023.zip,Peru,00:49,1,Chrome,Mobile,Portrait,"ANGLE (Imagination Technologies, PowerVR B-Series BXM-8-256, OpenGL ES 3.2)",8,2.4375,"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Mobile Safari/537.36","It took him 26s to get out of the how to play popup. Player didn't understand how to move right or left, only went straight forward.",1st run - 20s,Exit,,Only running ahead.,,
Hi Fi Snake,26-jul.-17,build023.zip,Venezuela,01:28,3,Chrome,Mobile,Portrait,"ANGLE (ARM, Mali-G57 MC2, OpenGL ES 3.2)",8,1.75,"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Mobile Safari/537.36","He tested the controls before starting go ahead playing. He died hitting the red barrier after passing trough the first gate. Before starting the next run, he pressed the robot and the clock button. He beat 32s in the 2nd run, died and didn't move in the 3rd run.","1st run - 16s
2nd run - 32s
3rd - didn't move",10s/4s = 7s,,He tried to go back and then hit the red barrier.,,
Hi Fi Snake,26-jul.-17,build023.zip,Indonesia,00:40,1,Chrome,Mobile,Landscape,Adreno (TM) 610,8,1.65,"Mozilla/5.0 (Linux; Android 14; V2205 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/150.0.7871.46 Mobile Safari/537.36 PokiApp/2.0.0+24","He quickly understood the controls and passed through the first 2 gates. But after the second one, he hit the red barrier.",1st - 24s,Exit,,He passed through the second gate and then hit the red barrier.,,
Hi Fi Snake,26-jul.-17,build023.zip,Indonesia,00:27,1,Chrome,Mobile,Portrait,"ANGLE (ARM, Mali-G68, OpenGL ES 3.2)",8,2.625,"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Mobile Safari/537.36","He started the run and churned in 7 seconds, he never passed through the first gate.",1st - 7s,Exit,,"He didn't lose control, he just gave up.",,
Hi Fi Snake,26-jul.-17,build023.zip,India,01:02,1,Chrome,Mobile (tablet),Portrait,"ANGLE (ARM, Mali-G57 MC2, OpenGL ES 3.2)",8,13.312.501,"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36",He started the run but never moved.,1st - 4s,Exit,,He didn't move.,,
Hi Fi Snake,26-jul.-17,build023.zip,Indonesia,00:43,1,Chrome,Mobile,Portrait,"ANGLE (Imagination Technologies, PowerVR Rogue GE8320, OpenGL ES 3.2)",8,2,"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Mobile Safari/537.36","He started the run and close to the 1st gate, he went right and hit the red barrier. I didn't understand if something bugged after he finished the run. He never started the second run. ",1st - 14s,Exit,,He went right.,,
Hi Fi Snake,26-jul.-17,build023.zip,India,00:33,1,Chrome,Mobile,Portrait,"ANGLE (ARM, Mali-G52 MC2, OpenGL ES 3.2)",8,2,"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Mobile Safari/537.36","He started the run, passed through the 1st gate and didn't move anymore. The walking red barrier hit the player. The image bugged, I believe the player just closed the game.",1st - 11s,Exit,,He stopped walking.,,
Hi Fi Snake,26-jul.-17,build023.zip,Vietnam,01:08,1,Chrome,Mobile,Portrait,"ANGLE (ARM, Mali-G68 MC4, OpenGL ES 3.2)",8,2.8125,"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Mobile Safari/537.36","He navegated through menu before started playing. He passed through 4 gates, but churned after the 4th. Between the 3rd and the 4th he even collect a yellow octahedron.",1st - 55s,Exit,,"He didn't lose control, he just gave up.",,
Hi Fi Snake,26-jul.-17,build023.zip,USA,01:39,2,Samsung Internet,Mobile,Portrait,Mali-G57 MC3,8,2.25,"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/30.0 Chrome/143.0.0.0 Mobile Safari/537.36","He started the run, passed through the 1st gate and went ahead without collecting anything. Close to the gate, he got back and hit the walking red barrier. In the second run, the same thing happened, but he didn't get back, he hit another barrier in the 2nd run, without collecting again. He didn't move rigth or left.","1st - 19s
2nd - 28s",9s,,"He didn't collect anything in both runs after the 1st gate. He didn't understood the controls, he didn't move right or left.",,
Hi Fi Snake,26-jul.-17,build023.zip,Vietnam,02:44,3,Chrome,Mobile,Portrait,"ANGLE (Qualcomm, Adreno (TM) 610, OpenGL ES 3.2)",8,2.75,"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Mobile Safari/537.36","He started the run, passed through the 1st gate and went too slow after the gate. The walking red barrier hit the player. He navegated the menu before the second run for about 30s. Same thing in the 2nd run, but he hit the barrier before the 3rd gate at this time. In the 3rd round, the player died for a barrier that fell from the top of the screen before the 3rd gate.","1st - 29s
2nd - 47s
3rd - 33s","30s/5s = 17,5s",,"I don't think he loose control, he was just slow.",,