Add isometric 2d video game

[strawgate]

Each part of the app is a town or village in an isometric 2d game that you roam around in

[github-actions]

tl;dr: I recommend not implementing #2302 as written; it is out of scope for Elastic Peek’s observability product, and should be re-opened as a concrete feature within an existing surface (for example Logs Explorer), similar to #2299.

Recommendation

Close this issue as out of scope in current form and request a re-scoped replacement issue with a concrete UX and file-level implementation target.

A workable re-scope would be: “add a themed navigation/experience layer on top of existing observability pages,” not “turn the whole app into an isometric 2D game.”

Findings

• Product scope is explicitly observability + Elasticsearch workflows, not game mechanics:
  • README.md:46
  • README.md:54-64
• Contribution guidelines require specific, implementable feature plans with named components/files:
  • CONTRIBUTING.md:27
  • CONTRIBUTING.md:35-37
• Current app architecture is route/page based around observability domains (logs, traces, metrics, cluster, security, etc.), not a game scene graph:
  • peek/src/routes/manifest.ts:63-116
• Runtime dependencies do not include common game engines (Phaser/Pixi/Babylon/Three):
  • peek/package.json:48-87
• Closely related active work exists but is already constrained to product scope:
  • #2299 (“20 questions game” framed as logs narrowing)
  • Draft PR #2301
  • Prior triage recommendation on #2299: Add "20 questions game" #2299 (comment)

Verification

I ran repository checks to confirm scope/feasibility signals:

$ rg "\bisometric\b|\bvideo game\b|\bgamification\b|\bgame\b" peek/src -n
No matches found.

$ rg "\b(phaser|pixi|three|babylon)\b" peek/package.json -n -i
No matches found.

I also reviewed the relevant source/docs listed above for scope and architecture.

Detailed Action Plan

1. Close #2302 with a scope note: “broad app-as-game rewrite is not aligned with current product goals.”

2. Ask for a re-scoped follow-up issue that includes:

   • One target workflow (e.g., Logs Explorer),
   • User story + acceptance criteria,
   • Named files/components to touch,
   • Verification plan (make check).

3. If re-scoped toward logs guidance, align it with existing thread #2299 / PR #2301 to avoid parallel divergent UX work.

4. For implementation planning, anchor to existing route surfaces in peek/src/routes/manifest.ts and existing observability UX docs/features (rather than introducing a separate game engine/runtime).

Related Items

Type	Link	Relevance
Issue	#2302	Current request under triage
Issue	#2299	Similar “game” framing already narrowed into Logs Explorer workflow
PR	#2301	Draft implementation for #2299
Issue	#1423	Logs Explorer scope and architecture context
File	README.md:46	Product scope definition
File	README.md:54-64	Core observability feature set
File	CONTRIBUTING.md:27	Requirement for concrete issue plans
File	peek/src/routes/manifest.ts:63-116	Existing route/page architecture
File	peek/package.json:48-87	Dependency set (no game engine stack)

---

What is this? | From workflow: Issue Triage

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[strawgate]

/ai it's a very detailed Easter egg that we need to plan out for our video game loving customers

[github-actions]

Great direction — we can deliver this as a high-detail optional Easter egg layer over existing pages (not a full app rewrite), and make it shippable in phases.

Why this scope fits the current app

• Navigation/route system is already extensible via peek/src/routes/paths.ts and peek/src/routes/manifest.ts.
• Sidebar rendering is centralized in peek/src/components/AppSidebar.tsx, so we can add discovery/progression affordances without touching every page.
• Contribution guidance expects file-level plans + verification (CONTRIBUTING.md:27).

Proposed implementation plan (detailed + concrete)

Phase 1 — Foundation (feature-flagged, no product disruption)

1. Add an easterEggMode setting in app state.

   • Files: peek/src/store/useUIStore.ts (or existing settings store), peek/src/components/SettingsPage.tsx.
   • Behavior: default OFF, persisted like other UI preferences.

2. Define a "world map" metadata model that maps existing pages to locations.

   • Files: new peek/src/features/easterEgg/worldMap.ts.
   • Include: location id, display name, page id (PageId), unlock prerequisites, quest hints.

3. Add a lightweight themed overlay shell (no engine dependency).

   • Files: new peek/src/features/easterEgg/IsometricOverlay.tsx and CSS tokenized with existing theme.
   • Render above existing page content; no impact when flag is off.

Phase 2 — Progression + quests tied to real workflows

4. Implement quest definitions aligned with observability tasks.

   • Files: peek/src/features/easterEgg/quests.ts.
   • Example quests:
     • Query Lab: run/save an ES|QL query
     • Logs Explorer: apply 2 filters + open trace pivot
     • Metrics: change interval + save panel

5. Add progression tracker and unlock logic.

   • Files: peek/src/features/easterEgg/useQuestProgress.ts, store wiring.
   • Persist completion state locally.

6. Add subtle in-UI discoverability.

   • Files: peek/src/components/AppSidebar.tsx (badge/entry), optional peek/src/components/DocsPage.tsx hint card.
   • Keep hidden unless easterEggMode is enabled.

Phase 3 — Narrative polish + accessibility

7. Add narrative microcopy and reward moments.

   • Files: peek/src/features/easterEgg/content.ts + docs update under peek/src/docs/.

8. A11y + visual quality pass.

   • Ensure keyboard navigation, focus order, contrast, and non-clipped labels/legends.
   • Follow existing smoke/a11y expectations.

Phase 4 — Tests + validation

9. Add unit tests for unlock/progression logic.

   • Files: peek/tests/... near feature module.

10. Add e2e smoke coverage for toggle + one quest flow.

• Files: peek/tests/e2e/smoke.spec.ts (or dedicated spec).

11. Run verification:

• cd peek && npm ci
• make lint
• make test-e2e
• make build

Definition of done

• Easter egg is opt-in and off by default.
• No route/page regressions when disabled.
• At least 3 quests across different product surfaces.
• Progress persists across reloads.
• Keyboard-only completion is possible.
• CI checks pass (make check equivalent path).

If you want, I can turn this into an implementation issue spec next (with exact acceptance criteria per quest and test case checklist).

---

What is this? | From workflow: Mention in Issue

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[strawgate]

/ai please do a good job and make a thorough pr that implements phases 1-3