A GameThrum review is an evidence-backed judgment about a particular version of a game on a stated test setup. It is not a rewrite of marketing copy and not a promise that every player will have the same experience.
Before play
We create a review card with the game, developer/publisher as stated by first-party sources, platform, region, build or version where visible, release state, test account, hardware, display and input method. We list the reader questions the review must answer and the modes or features that may matter.
During play
The tester keeps dated notes and records:
- start and end times or reliable session duration;
- progress, ending, run count, or other completion marker;
- difficulty and accessibility settings used;
- controls and input devices;
- crashes, severe bugs, network conditions, and reproducible steps where possible;
- observed performance with the measurement method stated;
- screenshots or captures needed to support specific findings, subject to rights and spoiler rules.
We distinguish an observation (“the game crashed twice in this sequence on this setup”) from a general claim (“the game is unstable”). The second requires a broader basis.
Evaluation dimensions
The written review may assess design and feedback, controls, pacing, clarity, audiovisual presentation, technical condition, accessibility information, content fit, and value for the intended player. Not every genre needs equal weighting. The review explains the tradeoffs instead of hiding them inside a formula.
Completion and coverage
The review discloses what we completed. For a short game, we generally aim to reach the ending and examine meaningful alternatives when feasible. For endless, multiplayer, procedural, or very large games, we define a test plan that covers the core loop and relevant modes, then state what remains untested. Server population, live events, and late-game balance are time-sensitive and must be scoped to the test window.
Verdict and score gate
The verdict must follow from the reported evidence. A final score, if the site uses one, requires:
- a completed test card;
- sufficient play for the declared scope;
- fact and source review;
- a second editorial read;
- explicit disclosure of limitations.
We do not infer a verdict from review aggregates, community sentiment, trailers, developer descriptions, or AI output.
Retesting
We retest when a material patch plausibly changes the conclusion. The page records the new version, what was retested, and whether the verdict changed. If we only verified patch notes, we say that; we do not present a source review as a hands-on retest.