How we verify what we publish, how we separate fact from opinion, and what happens when we get something wrong.
Three kinds of claim
Most accuracy problems in gaming writing come from blurring three very different things. We label them explicitly:
- Facts — verifiable statements. Release dates, technical behaviour, how a system in our own games works. These are checkable and we check them.
- Opinions — editorial judgements. "Pixel Dash is the best starting point" is our view, and we phrase it as one.
- Recommendations — advice based on experience. "Jump late rather than early" is a technique that works in our games; we say where it applies and where it does not.
Where a sentence could be read as a fact but is actually a judgement, we rewrite it.
Verifying claims about our own games
Most factual claims on this site are about software we wrote, so verification means checking the code and playing the game.
When a guide states a specific number — that the minimum reaction window is about 420 milliseconds, that gaps are capped at 55% of jump range, that the multiplier reaches 12× at an 80-item chain — those values come from the engine's source, not from memory. When the engine changes, the affected articles are updated.
Claims about how a game feels or which strategy works best come from extended play, and we frame them as the experience-based judgements they are.
Verifying external facts
For claims about gaming history, industry context, browser technology or accessibility standards, we require a reliable source. In practice that means, in rough order of preference:
- Primary technical documentation — web platform specifications, MDN Web Docs, browser vendor documentation.
- Official standards bodies — for example the W3C for accessibility guidance.
- Primary statements from developers or publishers about their own products.
- Established, editorially accountable publications with a correction process.
We do not use unattributed wiki summaries, content-farm articles or AI-generated summaries as sources for factual claims.
What we will not do
- Invent statistics. If we cannot cite a number, we do not use one. A vague but honest statement beats a precise fabricated one.
- Invent sources. Every study, paper or publication we name is real and findable. Fake citations are worse than no citations.
- Invent quotes. No manufactured expert commentary.
- Overstate certainty. Where the record is genuinely contested — which game "started" the endless runner genre, for instance — we say it is contested rather than picking a tidy answer.
- Make health claims. We will not assert that playing games improves reflexes, attention or cognition in general. The honest claim is that practising a game improves your performance at that game, and that is what we write.
Handling uncertainty
When something is uncertain we say so in the text, using the appropriate language:
- "widely credited with" — commonly attributed but not formally established;
- "commonly measured around" — a typical figure with real variation behind it;
- "in our engine" — true of our implementation, not of the genre generally;
- "in our experience" — an experience-based judgement rather than a measured result.
These are not hedges to avoid commitment. They are precision about what kind of claim is being made.
Review process
Before publication, every article is checked for: factual claims verified or removed; numbers about our games matched against the code; external claims sourced; opinions phrased as opinions; no invented data; internal links pointing to pages that exist; and dates that are real.
Corrections
We will get things wrong. When we do:
- Substantive factual errors — corrected in the text, noted on the page, and the updated date changed.
- Minor errors (typos, formatting, broken links) — fixed silently without changing the updated date.
- Outdated information — updated, with the updated date changed where the substance changed.
- Serious errors — if an article's core claim turns out to be wrong, we say so prominently rather than quietly editing it away.
We do not delete articles to hide mistakes. Corrections are part of the record.
Reporting an error
Email editorial@endlessrunnerarcade.xyz with the page, the claim you believe is wrong, and — if you have one — a source. Reader-reported errors are one of the most common reasons our articles get updated, and we are grateful for them.
Review schedule
Game pages are reviewed whenever the game they describe changes. Guides describing engine behaviour are reviewed when the engine changes. Everything else is reviewed periodically, and the updated date changes only when the content actually did.
Last updated: 15 septembre 2026