Refine bean oqfo: encounter rate display for time/weather variants
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -1,32 +1,83 @@
|
||||
---
|
||||
# nuzlocke-tracker-oqfo
|
||||
title: Improve encounter rate display for time/weather variants
|
||||
status: draft
|
||||
status: todo
|
||||
type: feature
|
||||
priority: normal
|
||||
created_at: 2026-02-10T14:04:27Z
|
||||
updated_at: 2026-02-10T14:04:27Z
|
||||
updated_at: 2026-02-14T21:17:00Z
|
||||
---
|
||||
|
||||
Improve how encounter rates are displayed in the tracker to support time-of-day, weather, and seasonal variants that exist in many Pokemon games.
|
||||
## Problem
|
||||
|
||||
## 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.)
|
||||
PokeDB data reveals that encounter rates vary by context across many games:
|
||||
- **Gen 2/4 (G/S/C, HG/SS, D/P/Pt, BDSP):** morning/day/night
|
||||
- **Gen 5 (B/W, B2/W2):** spring/summer/autumn/winter
|
||||
- **Gen 8 (Sw/Sh):** 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)
|
||||
- **Gen 9 (Sc/Vi):** overworld probability weights
|
||||
|
||||
Currently the seed format has a single `encounter_rate` field per encounter, which doesn't capture these variants.
|
||||
Currently the seed format and `RouteEncounter` model have a single `encounter_rate` field, which flattens all of this into one number.
|
||||
|
||||
## 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?)
|
||||
## Goal
|
||||
|
||||
Extend the data model and UI to support conditional encounter rates, so users can see which Pokemon appear under which conditions.
|
||||
|
||||
## Design
|
||||
|
||||
### Seed data format
|
||||
|
||||
Add an optional `conditions` field to encounter entries. When absent, the encounter has a flat rate (Gen 1/3/6 — no change needed). When present, it replaces `encounter_rate` with per-condition rates:
|
||||
|
||||
```json
|
||||
{
|
||||
"pokeapi_id": 163,
|
||||
"pokemon_name": "Hoothoot",
|
||||
"method": "walk",
|
||||
"encounter_rate": null,
|
||||
"conditions": {
|
||||
"night": 50,
|
||||
"morning": 10,
|
||||
"day": 0
|
||||
},
|
||||
"min_level": 2,
|
||||
"max_level": 5
|
||||
}
|
||||
```
|
||||
|
||||
For games without variant rates, the existing flat `encounter_rate` field is used unchanged.
|
||||
|
||||
### Backend changes
|
||||
|
||||
1. **New model `RouteEncounterCondition`** (one-to-many from `RouteEncounter`):
|
||||
- `id`, `route_encounter_id` (FK), `condition` (string), `encounter_rate` (int)
|
||||
- Conditions are free-form strings: `"morning"`, `"day"`, `"night"`, `"rain"`, `"spring"`, etc.
|
||||
2. **`RouteEncounter` model**: keep `encounter_rate` as nullable — null when conditions exist, populated when flat.
|
||||
3. **Seed loader**: detect `conditions` key in JSON, create `RouteEncounterCondition` rows accordingly.
|
||||
4. **API**: include conditions in route encounter responses (nested array under each encounter).
|
||||
|
||||
### Frontend changes
|
||||
|
||||
1. **AdminRouteDetail**: show conditions as sub-rows or a tooltip when hovering the rate column.
|
||||
2. **EncounterModal**: group by condition context when relevant (e.g. tabs for morning/day/night).
|
||||
3. **Type updates**: extend `RouteEncounter` type with optional `conditions: { condition: string, encounterRate: number }[]`.
|
||||
|
||||
## Checklist
|
||||
|
||||
- [ ] Update seed JSON schema: add optional `conditions` field to encounter entries
|
||||
- [ ] Create `RouteEncounterCondition` model with migration
|
||||
- [ ] Make `RouteEncounter.encounter_rate` nullable
|
||||
- [ ] Update seed loader to handle `conditions` entries
|
||||
- [ ] Update API serialization to include conditions
|
||||
- [ ] Update frontend types (`RouteEncounter`)
|
||||
- [ ] Update AdminRouteDetail to display condition-based rates
|
||||
- [ ] Update EncounterModal to show conditions contextually
|
||||
- [ ] Update seed data for at least one game per variant type (HG/SS, B/W, Sw/Sh) as proof of concept
|
||||
- [ ] Keep simple display for games with flat rates (no regression)
|
||||
|
||||
## 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
|
||||
|
||||
- For Nuzlocke play, availability ("appears during rain") matters more than exact percentages — consider a simplified view option
|
||||
- Keep UI uncluttered for simple cases (Gen 1/3/6)
|
||||
- Condition strings should use a consistent vocabulary (define an enum or reference list)
|
||||
- Seed data updates for all games can be done incrementally after the infrastructure is in place
|
||||
Reference in New Issue
Block a user