How I Review Games

The playing experience, the reasons behind the scores, and the context to help you decide whether to buy.

Since 6 November 2026, reviews have been one of Wordtura’s main priorities. These guidelines explain how I assess games, from playing experience to scores and the final recommendation.

• These guidelines apply in full to reviews published after the Battlefield 6 Open Beta review, which marks their initial implementation.
• Earlier reviews will receive only minor adjustments, such as clarifying context or correcting scores, without changing the article’s core perspective.

The main consideration is how the game actually feels to play: whether it is enjoyable, well put together, makes me want to continue, and consistently delivers the experience it promises.
Technical data such as FPS, resolution, or specifications provides supporting context rather than being the focus of the assessment.

Visual assessment considers two things together:

1. Presentation quality: polished or rough, clear or tiring, consistent or disjointed.
2. Art direction: visual identity, character and environment design, and how these support gameplay.

Graphics are not judged solely on how elaborate or detailed they are. Simple visuals can score highly when they are consistent, clear, and functional. Visuals that are unclear, inconsistent, or make gameplay harder to read count against the assessment.

Audio and music are assessed by their function and the atmosphere they create. They may receive separate scores: Audio covers sound effects, ambience, positional information, and voice acting quality; Music covers composition, variety, and how it fits gameplay moments. I consider:

• SFX quality: clarity and impact of footsteps, gunfire, explosions, and ambience, including consistency during busy scenes.
• How music fits the moment: supporting the atmosphere without disrupting focus.
• Sound information and positioning: particularly in competitive games, how well audio helps identify situations and the direction of threats.
• Use of ambience and silence: whether atmosphere feels intentionally built rather than simply empty.

Performance is assessed from a player’s perspective, focusing on its effect on the actual experience. I consider:

• Framerate stability during exploration, combat, and busy scenes.
• Loading times: whether they are reasonable and frequently interrupt the flow of play.
• Stutters, freezes, and crashes: their frequency and severity.
• The impact of technical problems, from minor interruptions to disrupted gameplay.

Technical numbers are included where relevant and only in as much detail as needed. The focus remains on their effect on play.

The assessment applies to the hardware, platform, settings, and version I use. Recording or livestreaming conditions are mentioned when relevant to an issue. If the cause of a crash or stutter is unknown, I report what happened without claiming to know its cause or assuming every player will experience it.

This context helps readers compare the experience with their own setup.

Additional aspects are used when the game’s main focus is not fully represented by the standard categories. Examples include:

• Complex system simulation: economics, management, physics, or AI.
• Creator tools or creative modes: editors, freedom of expression, and stability of creative features.
• Unusual design approaches: experimental structures, distinctive progression, or concepts that depart from genre conventions.
• A specific feature as the main selling point: asymmetric co-op, extensively branching narratives, or distinctive online integration.

Additional aspects do not automatically raise the score. The assessment is explained so readers understand what is being judged and why it matters.

I assess the game entirely as a new release, focusing on the current experience: gameplay, visuals, audio, performance, content, and value or monetisation systems. Nostalgia is not used as a benchmark.

The original remains the main comparison for assessing changes: whether this is essentially the same game with clearer visuals, or whether gameplay, systems, and the experience have changed meaningfully. If the changes have little practical effect on how it feels to play, I flag that as an important caveat. The final focus remains how the game feels to play now.

For pre-release builds, including open betas and alphas, the aim is to give an honest picture of the build at the time of testing. It is not an assessment of the final release.

The assessment covers:

• The gameplay loop and basic comfort.
• Controls, camera, and input response.
• Matchmaking and server conditions, where applicable.
• Basic technical stability.

Important points:

• Only content available during the test is considered. Locked or promised features do not affect the assessment.
• Monetisation is briefly noted if already active. If it is unclear, it is not used as a main deciding factor.
• The review always clearly identifies the build as pre-release.

Pre-release verdicts still have two options:

• Recommended to try during the test period, or
• Not Recommended for the current test period.

After the full release, I may update or rewrite the review under the regular criteria if I play that version again. A pre-release review describes the build tested and does not guarantee the condition of the final release.