Fact-Checking Policy

Three classes of claim

Almost everything we publish falls into one of three categories, and each is verified differently.

1. Claims about the games on this site

These are the easiest to verify and the most common, because most of our writing is about our own games. Every such claim is checked against the source file that implements it.

• Combo thresholds — js/game/scoring.js
• Power-up durations, radii and multipliers — js/game/powerups.js
• Collectible tiers and point values — js/game/collectibles.js
• Difficulty presets, ramp times and life counts — js/game/difficulty.js
• Level generation rules and chunk demands — js/game/procedural-generation.js
• Per-game mechanics — the game's own module under js/games/

Those files are served to your browser, so any reader can check our numbers against the code that produces them. That is the strongest form of verification available to us and we use it wherever we can.

2. Claims about web technology

HTML5, the canvas 2D context, the Web Audio API, LocalStorage, pointer events, requestAnimationFrame, prefers-reduced-motion and related technologies. These are checked against primary documentation: the relevant W3C or WHATWG specification, or MDN Web Docs where it accurately summarises the specification.

We do not cite tutorial blogs as authority for how a browser API behaves. Where behaviour differs between browsers, we say so rather than describing the behaviour of one browser as universal.

3. Claims about game design

Statements like "coyote time makes platforming feel fairer" are design judgements, not facts, and we write them as judgements. Where a design claim can be grounded in something concrete — the actual jump-reach formula our generator uses, the measured particle budget, the specific cap on a difficulty curve — we ground it there and show the mechanism.

What we treat as a reliable source

• This site's own source code, for claims about this site's games.
• W3C and WHATWG specifications, for how a web standard is defined.
• MDN Web Docs, for practical API behaviour and browser support.
• WCAG and WAI documentation, for accessibility guidance.
• Official browser vendor documentation, for vendor-specific behaviour.

We do not treat as reliable: aggregator sites that republish others' content, AI-generated summaries, marketing material, or any statistic whose original source cannot be located.

Numbers and statistics

A number in an article on this site is one of three things: a value read from our own code, a figure from a named and linked source, or a clearly labelled estimate. There is no fourth category.

We will not publish player counts, download figures, market-size numbers or engagement statistics that we cannot source. This applies with particular force to claims about our own popularity: we have no server collecting analytics, so we have no such data, and we will not invent it to look established.

Before publication

1. Every factual sentence is read specifically to ask "how do I know this?"
2. Claims about our games are traced to the implementing file and the value confirmed.
3. Claims about web technology are traced to primary documentation.
4. Anything that survives neither check is cut or rewritten as an explicit judgement.
5. External links are opened and confirmed to support what they are cited for.
6. The game being described is played again, to confirm the described behaviour matches the shipped behaviour.

After publication

Articles are re-checked when the thing they describe changes. The most common trigger is a game being rebalanced: when a difficulty preset or a power-up value changes, every article that quotes the old number is found and updated.

Technology articles are reviewed when browser behaviour changes in a way that affects them.

Corrections

When we get something wrong:

1. The error is fixed as soon as it is verified.
2. The article's "updated" date changes.
3. Where the error was substantive — a wrong number, a wrong mechanic, a wrong technical claim — a correction note is added to the article stating what was wrong and when it was fixed.
4. Typographical fixes do not get a note, and do not change the update date.
5. Pages are not silently deleted to hide a mistake.

Report an error to editorial@playfoodarcade.xyz. Please include the page URL and, if you can, what the correct information is. Corrections from readers are welcome and are taken seriously.

Independence

No advertiser, partner or commercial relationship influences whether a claim is published or how it is framed. The editorial policy covers this in full.

Frequently Asked Questions