About the experiment

A guessing game built to make caching visible through repeat play.

Pokemon Guesser started as a React Query experiment wrapped in a silhouette game. The live route stays focused on play, while this page explains why seeded runs and cached API responses make the loop interesting.

Back to the challenge

What was being tested?

The underlying experiment was about using React Query against the public PokeAPI. A guessing game gave the data layer a clear job: fetch one Pokemon at a time, reuse entries that were already seen, and keep the round flow fast when the same data appeared again.

How the data loop works

Each round derives a Pokemon id from a numeric seed and the current round index. The app fetches that id with React Query using a stable query key, so the browser can keep a recently seen Pokemon warm in the cache instead of treating every round as brand new work.

The shared query client currently gives queries a short stale window, which is enough for repeated runs, quick reveals, and immediate retries to benefit from cached data without turning the app into a static dataset.

Why a seeded challenge fits

Seeds make the game reproducible. The same number always yields the same ten-round lineup, which makes it easy to replay a run, compare scores with someone else, and notice when the data layer is reusing work from a previous attempt.

That repeatability also keeps the guessing game fair. Two players can take the same challenge and know they saw the same sequence of silhouettes.

What to pay attention to

The live route is intentionally short: silhouette, guess, reveal, move on. Pay attention to how little explanation the loop needs once the seed and answer normalization are understood.

The game accepts common naming variations by normalizing punctuation, accents, and gendered symbols before comparing answers. That keeps the friction in the visual guess, not in exact string matching.

Limits and tradeoffs

The project uses a public API, so reliability and response speed are partly external. The UI needs to handle loading and retry states gracefully instead of assuming the next Pokemon will always arrive instantly.

The game also keeps the data model simple. It treats one Pokemon entry as one answer rather than modeling every possible form, ruleset, or difficulty tier. That constraint keeps the guessing loop readable and lets the caching experiment stay easy to see.