Daniel Carter

Senior Gaming Researcher and Arcade Content Specialist. Daniel Carter is the editorial identity behind Robot Arcade - the person who builds the games and writes the guides that explain them.

About this byline

Robot Arcade is a small independent project rather than a newsroom, and Daniel Carter is the single editorial identity it publishes under. Every game and every guide on the site comes from the same place, which is unusual enough to be worth stating plainly rather than implying a staff that does not exist.

The portrait on this page is an illustration, not a photograph. A stock headshot would imply that a specific real person stands behind these pages, and a generated photograph of someone who does not exist would be worse - a claim about a human being that simply is not true. An obvious drawing avoids both.

No employment at any named company is claimed anywhere on this site, because none could be verified by a reader, and an unverifiable credential is not a credential.

Areas of expertise

Browser game development with HTML5 Canvas and vanilla JavaScript, including the whole of the engine these twelve games share - input handling, fixed-step game loops, collision, particle systems and runtime audio synthesis.

Arcade game design specifically: difficulty curves that rise inside a run rather than across levels, scoring systems that reward precision over persistence, telegraph and timing-window design, and the question of what makes a short game worth replaying.

Robot and science-fiction game genres, mech combat systems, and the practical business of making a game readable - silhouette design, colour languages and the difference between a game that is hard and a game that is unclear.

Editorial interests

Accessibility in games that are fundamentally about reaction speed, which is a harder problem than it is usually treated as. Every game here supports keyboard play, respects reduced-motion preferences, and avoids relying on colour alone to carry information.

Honest games writing. A great deal of what is published about games is marketing copy with the labels removed, and a guide that cannot tell you why something works is not a guide. The bias of this site is toward explaining mechanisms rather than listing tips.

Corrections and contact

Guide corrections are the fastest thing to get actioned on this site, because they affect whether it is accurate. If a guide describes something the game does not do, that is a bug in the guide.

The contact page is the way to report one, along with bugs, accessibility problems and game suggestions. The corrections process is described in the editorial policy.

Guides by Daniel Carter

Frequently asked questions

Is Daniel Carter a real person?

It is the editorial identity this site publishes under, covering the games and the written guides. No employment history or credential is claimed that a reader could not verify, and the portrait is an illustration rather than a photograph.

Who writes the guides?

The same person who builds the games, which is why the numbers quoted in them come from the source rather than from estimates.

How do I report an error in a guide?

Through the contact page, choosing 'Guide correction'. Corrections are prioritised over everything except bugs that stop a game working.

Are guides updated?

Yes, when the game they describe changes. An updated date is only shown on a guide that has genuinely been revised.