Our test record is designed to let a reader understand exactly what supports a claim.
The public test box
Hands-on reviews and tested guides should show:
- platform and storefront;
- game version/build when available;
- test dates;
- hardware and operating system relevant to the result;
- display resolution and major graphics preset for performance claims;
- controller, keyboard/mouse, or other input;
- approximate play time and progress;
- modes tested and not tested;
- network region/connection context for online play;
- copy/access type if relevant to editorial independence;
- reviewer limitations, including features we could not reproduce or access.
Reproducible checks
A technical or settings claim needs a defined method. We record the starting state, steps, result, number of attempts when useful, and evidence. Frame-rate, battery, latency, load-time, and accessibility claims must name the tool or observable criterion. We do not turn a single short run into a universal benchmark.
Different games need different plans
- Narrative games: progress, ending state, route choices, spoilers, and skipped branches.
- Roguelikes: run count, unlock state, difficulty, and build variety sampled.
- Multiplayer/live games: mode, region, queue window, party size, server conditions, and patch.
- Puzzle and guide coverage: exact level/version, solution verification, alternate input where relevant, and spoiler boundaries.
- Early Access: current build, roadmap claims attributed to the developer, missing systems, and the fact that the game may change.
Accessibility
We report available settings from the live build and describe their observed effect. A menu option is not proof that every player can use the game comfortably. We avoid declaring a game “accessible” for everyone. When possible, we test remapping, subtitles, text, contrast/color options, camera motion, timing demands, save behavior, and input requirements, then state our test limits.
What public sources can and cannot prove
Official pages can support platform availability, listed features, developer identity, release state, system requirements, and stated modes. Only actual play can support judgments about feel, usability, pacing, difficulty, quality, bugs on our setup, or whether a feature works as expected.
If a page has no completed test record, its play-dependent sections remain labeled Needs hands-on testing and cannot be published as findings.