- Complete exploration of automated data sources (q5vd): PokeDB.org identified as ideal single source of truth with JSON data export - Add bean for PokeDB.org data import tool (bs05) - Add bean for improving encounter rate display with time/weather variants (oqfo) - Mark branding cleanup bean (xvaw) as completed Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
32 lines
1.6 KiB
Markdown
32 lines
1.6 KiB
Markdown
---
|
|
# nuzlocke-tracker-oqfo
|
|
title: Improve encounter rate display for time/weather variants
|
|
status: draft
|
|
type: feature
|
|
created_at: 2026-02-10T14:04:27Z
|
|
updated_at: 2026-02-10T14:04:27Z
|
|
---
|
|
|
|
Improve how encounter rates are displayed in the tracker to support time-of-day, weather, and seasonal variants that exist in many Pokemon games.
|
|
|
|
## Context
|
|
|
|
PokeDB.org data reveals that encounter rates vary significantly by context across different games:
|
|
- **Gen 2 / Gen 4 (G/S/C, HG/SS, D/P/Pt, BDSP):** rates vary by morning/day/night
|
|
- **Gen 5 (B/W, B2/W2):** rates vary by season (spring/summer/autumn/winter)
|
|
- **Gen 8 (Sw/Sh):** rates vary by weather (clear, cloudy, rain, thunderstorm, snow, etc.)
|
|
- **Gen 8 (Legends Arceus):** time + weather boolean conditions
|
|
- **Gen 9 (Sc/Vi):** overworld probability weights (not traditional encounter rates)
|
|
|
|
Currently the seed format has a single `encounter_rate` field per encounter, which doesn't capture these variants.
|
|
|
|
## Goals
|
|
- Design a display format that lets users see encounter rates for different conditions (e.g., tabs or tables for morning/day/night)
|
|
- Determine how to extend the seed data format to store variant rates
|
|
- Decide which level of detail is useful for Nuzlocke tracking (do players care about exact weather rates, or is "available during rain" sufficient?)
|
|
|
|
## Considerations
|
|
- Keep it simple for games with single rates (Gen 1, Gen 3, Gen 6)
|
|
- For Nuzlockes, the key question is usually "what can I encounter here?" — exact rates are secondary but useful for planning
|
|
- The UI should not become cluttered for simple cases
|
|
- This may affect the backend encounter model, seed format, and frontend display |