Identify the Arcade Version Before Comparing It

A familiar title is only the beginning of an arcade record. Regional releases, program revisions, conversions, and unofficial variants can share much of their name. When two games behave differently, first establish what each one is. Otherwise a discussion about difficulty or controls can quietly become a comparison of different versions.

Here is a practical method for reading a cabinet page, using the kind of records held by Retro-Arcade. Catalogue metadata is a navigation aid and a statement to verify. It is not, by itself, proof of historical accuracy, compatibility, or permission to distribute a game.

Read the fields as separate claims

A worked catalogue example

Our Galaga record identifies Namco revision B in its URL. That gives a reader a more precise starting point than “Galaga”. It still does not prove that a different Galaga release has identical timing, that every sound has been reproduced, or that a saved state from another core will load.

Write down three statements separately: “the page labels this set as revision B”; “the running title screen displays these credits”; and “this core successfully ran the particular sequence I observed”. The first is catalogue evidence, the second is a program observation, and the third is a limited compatibility observation. They support different conclusions.

Controls are a useful cross-check

Street Fighter II uses six attack buttons: three punches and three kicks. A description calling it a three-button cabinet is missing half the attack layout. Capcom’s explanation of classic controls describes that established six-button arrangement.

Also distinguish directions from hardware. A four-way game needs up, down, left, and right without intentional diagonal actions. An eight-way game can use diagonals. Neither description tells you whether a modern keyboard is comfortable. In our cabinet pages, the displayed key mapping answers a different question: how to send an input in this browser.

Why a ROM-set name is not enough

MAME documents parent and clone sets, shared files, and different ways to organise archives. “Clone” is a technical relationship in that system; it does not automatically mean a bootleg. A regional or revised release can share data with its parent. Missing shared files can explain why a set fails even when its main archive is present.

For a compatibility report, include the emulator core and version as well as the set. Do not rename random files to make labels match. File contents, dependencies, and the core’s expectations matter. MAME’s About ROMs and Sets is the primary reference for that distinction.

Compare scores on a defined basis

Before comparing two scores, check the version and the rules: lives, difficulty, continues, and any other relevant settings. A number without that context is incomplete evidence. Different controllers also create different playing conditions, even where the scoring program is the same.

Retro-Arcade’s ranked support is tied to particular game IDs and state decoders. It is not a promise that a result can be compared directly with every arcade competition or home conversion. Use the ranked page to find the supported boards and the verification guide to understand its limits.

Send a correction that can be checked

A useful correction includes the page address, the disputed field, the proposed replacement, and a specific source such as a manual page, publisher record, or code reference. “This is wrong” starts a conversation; “this field confuses the licensed publisher with the developer, and here is the credit” provides something an editor can resolve.

If evidence conflicts, we should record uncertainty instead of inventing a person or date. A missing creator credit is preferable to a confident attribution without support. Send evidence through Contact.