This page explains how claims published on Tennis Arcade Games are verified, how sources are judged, how opinion is kept separate from fact, and what happens when we get something wrong.
Last reviewed: 15 September 2026.
The four kinds of claim we publish
Verification is not one process. What counts as adequate checking depends on what kind of claim is being made, so we sort every claim into one of four categories and treat each differently.
1. Claims about our own games
Examples: "the strike window starts at 150 milliseconds", "the opponent's maximum tracking speed is 82% of court width per second", "a second serve carries a 40-point penalty".
Verification: read directly from the game's source code before publication, and re-read at the fact-check stage. These are the strongest claims on the site because the source is definitive and we control it.
Risk: the code changes and the article does not. This is mitigated by treating any tuning change as requiring a same-change update to every page that quotes it.
2. Verifiable external facts
Examples: release dates, hardware specifications, when Flash reached end of life, what a court ruling said.
Verification: at least one primary or authoritative source, and where the claim is load-bearing for an article's argument, a second independent one. Primary sources are strongly preferred — a laboratory's own account of its own machine beats a summary of it.
Risk: circular sourcing, where several apparently independent sources all trace back to one unreliable original. This is a real and common problem in games history and is the main reason we prefer primary material.
3. Contested or poorly evidenced claims
Examples: the clock-face origin of tennis scoring, whether reaction training transfers between tasks, the size of the browser games market.
Verification: these are published only with the uncertainty stated in the text. We do not resolve a genuinely open question for the sake of a cleaner sentence. Where a story is popular but shakily evidenced, the article labels it folklore.
Risk: readers skim past hedging. Mitigated by putting the caveat in the main text rather than a footnote, and by using a visible callout where the claim is prominent.
4. Opinion and judgement
Examples: "a free charge mechanic is a delay pretending to be a decision", "ending on a single miss makes the score more meaningful".
Verification: none is possible, so the job is labelling. These are written in language that makes their status obvious — "we think", "in our view", "the design argument for this is" — and they are never presented as findings.
How we judge a source
Sources are ranked, and a lower-ranked source is not used to support a claim that needs a higher-ranked one.
- Primary material. Source code, official documentation, court records, an organisation's own account of its own work, technical specifications.
- Direct observation. Our own testing, described as such, with the method stated so a reader can judge it.
- Established secondary sources. Reference works and journalism with named authors, visible editorial standards and a correction history.
- Community sources. Forums, wikis, fan documentation. Occasionally the only record of something. Used only when labelled, and never as the sole support for a load-bearing claim.
Sources we will not use: content farms, AI-generated summaries, sites that do not name their authors, and any page whose claims cannot be traced to something further upstream. If we cannot find out where a fact came from, we do not repeat it.
Three areas that need extra care
Some subjects that recur on this site are unusually easy to get wrong, and we apply additional caution to each.
Early games history. Much of it was reconstructed from memory decades after the fact, surviving hardware is rare, and several widely repeated anecdotes have been shown to be embellished. We prefer institutional primary sources, we avoid superlatives like "the first", and where a claim depends on a definition we state the definition.
Reaction time and training effects. There is a genuine research literature here and it does not support the claims commonly made in gaming content. Practising a specific task improves that task; transfer to untrained tasks is contested. We will not tell you that a browser game will make you faster at anything else.
Market and audience figures. Browser gaming statistics vary enormously between sources because the definitions and methods differ. We either cite a specific source with its method, or we omit the number. We do not publish a figure we cannot attribute, and we never invent traffic or user numbers about this site.
Keeping fact and opinion apart
A design article is mostly opinion, and that is legitimate as long as it is legible. Three devices keep the distinction visible:
- Language. Factual claims are stated flatly. Judgements use explicit markers — "we think", "the argument for this is", "in our experience".
- Callouts. Editor's notes are visually distinct from body text, and anything inside one is our view unless it cites a source.
- Attribution. Where a claim comes from our own code we say so, which tells the reader both that it is reliable and that it applies only to our games.
The correction procedure
When an error is reported or found:
- Acknowledge. Reports sent through the contact page are acknowledged, normally within a few days. One person reads them.
- Verify. The claim is re-checked against its original source, not against the report. A report can be wrong too.
- Classify. Typographical, factual, or substantive — each is handled differently, as below.
- Correct. The page is updated and rebuilt.
- Record. The last-updated date moves, and anything beyond a typo gets a visible dated note on the article.
- Reply. Whoever reported it is told what changed.
What gets a visible note
| Type | Example | How it is recorded |
|---|---|---|
| Typographical | Spelling, punctuation, a broken link | Fixed silently; no date change |
| Clarification | Rewording something ambiguous without changing its meaning | Last-updated date moves |
| Factual | A wrong number, date or mechanic description | Dated correction note on the article |
| Substantive | A conclusion or recommendation that was wrong | Prominent dated note explaining what changed and why |
We do not delete an article to make an error disappear. If a piece is beyond repair it is rewritten, and if it should never have been published it is withdrawn with a note saying so at its original address.
Why the dates can be trusted
Every article shows a publication date and a last-reviewed date, and both are real. The last-reviewed date moves when the page is actually looked at by a person — either because something changed or because it came up on the twelve-month review schedule.
We mention this because date manipulation is common. Refreshing a date to appear current, when nothing has been checked, is a small deception with a real cost: it removes the reader's ability to tell how old the information is. If our date has not moved, nobody has looked at that page recently, and you should weigh it accordingly.
Reporting an error
Please do. Corrections are the cheapest possible improvement to the site, and a reader who takes the time to report one is doing us a favour.
The most useful reports include the page address, the specific claim, and — if you have one — a source. Send them through the contact page, choosing "Correction" as the reason.