Pebble Visual Audit

Evidence boundary

This audit is based on live browser inspection of https://funday.gg/play/pebble at desktop and mobile viewport sizes, inspection of the public iframe DOM and computed styles, source review of games/pebble/, and the repository’s deployment notes. The audit observed gameplay boot, pointer shooting, score updates, multiball, multiplier feedback, free-ball status, and game-over rendering.

The public audit did not prove a level-two transition. Claims about stale production artifacts or theme races are hypotheses until the deployed iframe asset identity and first-paint sequence are captured.

Executive verdict

Pebble is playable but visually fragmented. The player sees a generic Funday play shell and a separately designed canvas game with different hierarchy, surfaces, shadows, overlay treatment, and theme timing. The result reads as two products stacked together rather than one intentional Funday game.

shell:
  issue: generic play chrome with excessive elevation
iframe:
  issue: bespoke HUD and gradient-heavy overlays
composition:
  issue: board, metrics, controls, and letterbox do not form one surface
confidence:
  live_observations: high
  stale_artifact_hypothesis: unverified
  theme-race_hypothesis: plausible, needs first-paint proof

Live findings

Play shell

  • The navbar uses shadow-[var(--shadow-2)]; the current token is a large 0 16px 40px shadow intended for a much larger elevated surface.
  • The active GamePill combines a pink/purple color mix, primary border, hover lift, and shadow. It reads as an arbitrary theme-generated capsule rather than restrained game context.
  • Play mode hides overflow and drawer chrome but does not establish a Pebble-specific composition.
  • Fullscreen controls and the game canvas appear as separate layers, with a narrow lower strip and large unused space around the game.

Pebble iframe

The live iframe URL is /games/assets/pebble/build/?embed=1&theme=themeable. The canvas is a separate static artifact from frontend/build/.

Observed gameplay composition:

  • Score, level, multiplier, meter, remaining pegs, trajectory, and FREE BALL occupy unrelated positions.
  • The mobile canvas is letterboxed with a large low-information region.
  • FREE BALL is too small to read comfortably and looks like a random button even though it is a gameplay target.
  • Multiball feedback competes with top HUD elements.
  • The trajectory line resembles debug output rather than a polished aim affordance.

Observed game-over composition:

  • Pink/red glow behind the heading.
  • Yellow/blue high-score ribbon treatment.
  • Oversized blue score slab.
  • White translucent stat cards.
  • Pale yellow all-time-best panel.
  • Cyan-to-blue-to-purple PLAY AGAIN gradient.

This is the iframe’s own visual system, not only the Funday shell. It should be replaced with one semantic Daisy-style surface, one accent hierarchy, and a single primary CTA.

Root causes

  1. Split visual ownership: shell and iframe have separate layout and styling systems.
  2. Split build ownership: frontend/build/ and games/pebble/build/ deploy independently.
  3. Theme multiplicity: document startup theme, Funday theme state, iframe theme query/bridge, and canvas token resolution can make separate decisions.
  4. Elevation inflation: normal navigation and small controls use card-sized shadows.
  5. Metrics without composition: HUD values are visible but not grouped into a readable game status rail.
  6. Overlay decoration replacing hierarchy: game-over and feedback screens use gradients and effects where semantic structure is needed.

Target visual contract

surfaces:
  page: base-200
  board: base-300
  hud: base-100
  overlay: base-100
semantic_roles:
  launcher: primary
  multiball: secondary
  special_pegs: accent
  orange_pegs: warning
  clear: success
  game_over: error
rules:
  - "Prefer Daisy semantic tokens over bespoke gradients"
  - "Use shadow-sm for normal gameplay surfaces"
  - "Reserve shadow-xl for modal overlays"
  - "Do not use color as the only peg distinction"

Accessibility findings

Canvas-only state needs a DOM equivalent for score, level, multiplier, remaining orange pegs, meaningful bonuses, and terminal results. Play Again, Continue, Pause, and Restart must be real keyboard-accessible buttons. Reduced-motion users need a non-animated equivalent for confetti, score popups, bucket flash, and overlay transitions.

Completion criteria

  • Shell and iframe share one resolved theme before visible canvas paint.
  • Board, HUD, action area, and overlay read as one Pebble surface on desktop and mobile.
  • Game-over and level-clear screens use semantic Daisy surfaces with no decorative gradient stack.
  • The exact public route is screenshot-verified after both relevant artifacts are deployed.
  • The iframe build identity is known and matches the intended Pebble source release.

Ask Docs

AI assistant to help answer questions about the documentation. Answers are read-only and cite docs/source.

Hi! How can I help you with the documentation today? Answers are read-only and cite docs/source.

Ctrl+Enter to send