Fact Checking Policy

Last updated: 2026-09-15

The three kinds of claim we make

Different claims need different verification, so we separate them explicitly.

1. Claims about our own games

Example: "the shield capsule absorbs one ball", "the descent interval is twelve seconds", "a bonus brick is worth 60 points".

How we verify: by reading the engine source and the game's configuration, and by playing the game to confirm the behaviour matches. These are the strongest claims on the site, because we control both the code and the article.

Risk: a game is retuned and an article is not updated. Game articles are therefore re-checked whenever the game they describe changes.

2. Claims about how games generally work

Example: "most brick breakers determine the rebound angle from the paddle contact point", "collision is usually resolved on the axis of least penetration".

How we verify: against documented techniques, published tutorials and observable behaviour across multiple games. Where a practice is common but not universal we say "most" or "usually" rather than "all".

Risk: over-generalising from our own implementation. We flag where our engine differs from common practice.

3. Historical claims

Example: "Breakout was released by Atari in 1976", "Arkanoid introduced falling capsules in 1986".

How we verify: against reference sources, and by preferring the most conservative version of a story. Dates and publishers are well documented. Attribution of ideas to individuals frequently is not.

Risk: repeating a widely circulated claim that has never been verified. This is the largest risk on the site, and it is handled by the rules below.

How we handle contested history

Arcade history from the 1970s is full of stories that everyone repeats and few people have sourced. Our rules:

• Attribute rather than assert. "Wozniak has said that..." rather than "Wozniak proved that...".
• Separate roles. Concept, engineering and production credit are different things, and conflating them creates most of the genre's historical confusion.
• Prefer the boring version. Where a dramatic and a mundane account compete, and the evidence is equal, we use the mundane one.
• Say when something is disputed. Readers can handle uncertainty; they cannot handle being misled.
• Avoid precision we do not have. No invented exact dates, sales figures or development timelines.

Sources we use

Primary, for gameplay: our own source code, and the games themselves.

Technical references: MDN Web Docs for web platform behaviour - Canvas, requestAnimationFrame, Pointer Events, Web Audio, collision techniques.

Historical references: encyclopaedic references such as Wikipedia as a starting point and for its citations, museum and archive material such as the Computer History Museum, and preservation projects such as the Internet Archive's Internet Arcade.

Wikipedia is treated as a pointer to sources rather than as a source in itself wherever a claim matters.

What we will not publish

• Invented statistics of any kind - player counts, visitor numbers, ratings, survey results.
• Fabricated testimonials, reviews or endorsements.
• Awards, partnerships or credentials we do not have.
• Structured data describing ratings or reviews that do not exist.
• Precise historical details we cannot source.
• Claims about other companies' games that we have not verified.

If a section of an article would be stronger with a statistic and no reliable statistic exists, the section is written without one or removed. It is never filled with an estimate presented as data.

Reporting an error

Email editorial@brickbreakergames.xyz with:

• The page URL.
• The specific statement you believe is wrong.
• What you believe is correct, and a source or reproduction steps if you have them.

Reports about game behaviour are especially useful, because a discrepancy usually means either the article or the game has a bug.

How corrections are handled

1. Acknowledge. We reply to confirm we have received the report.
2. Verify. We check the claim ourselves rather than taking either version on trust.
3. Correct. If the report is right, the page is fixed.
4. Record. A correction that changes the meaning of an article is noted on the page, with the date and what changed. Typographical fixes are made silently.
5. Update the date. The "last updated" date changes, because the content genuinely changed.
6. Review neighbours. If the error appears elsewhere on the site, those pages are corrected too.

We do not quietly delete pages to make an error disappear, and we do not argue with a correct correction.

Our own accountability

Every article names its author, who is responsible for its accuracy. Sources are linked. Update dates reflect real changes. If we cannot verify something, we either say so or leave it out.

See also our editorial policy and about page.