Sort
Legend

No games match your current filters.
Try clearing a filter, tag, or your search.

Mechanics
Most similar

About Retro Mechanics DB

A reference tool that catalogs the gameplay mechanics of retro-era titles, roughly 1980 to 2000, and maps each mechanic to how you'd actually build it in a game engine. It's organized around the systems games are made of, not the genres they're sold under.

Why mechanics, not genres

This project exists to support learning game development through mechanics research: studying how games are built, as discrete systems and reusable patterns, rather than as finished products. The motivating question is what makes these games good: which mechanics and design ideas are worth taking inspiration from, or reimplementing from scratch as a learning exercise.

Genre is too coarse for that. "Platformer" or "RPG" says almost nothing about the systems underneath. So the catalog is built around mechanics, naming each one, mapping it to how it would be implemented, and showing which games share it: turning a pattern into something you can reach for when designing your own systems.

What's in scope

The catalog

The dataset holds 309 games. Each entry records its title, studio, year, and original platform; its popularity tier; the set of mechanics it uses; a rough 0–100 complexity rating; and a perspective (the camera/spatial framing, from 2D side-scrolling through isometric to full 3D). Most entries also carry a short Wikipedia summary, shown on the detail card with a link back to its source.

Each mechanic also has its own reference page: definition, the games that use it, and a Godot implementation recipe: browse all 54 mechanics →

One honest caveat: complexity is the single field that's a judgment rather than a fact. Everything else is verifiable, but complexity is hand-assigned with no formal rubric. Trust the extremes; treat the middle band (~45–65) as approximate, not a precise ranking.

The mechanics vocabulary

A controlled set of about 54 mechanics is the heart of the tool. Every tag a game can carry comes from this vocabulary, so the same mechanic is always named the same way and games stay cross-referenceable. Each mechanic has a plain-language definition and a note on how you'd implement it in a game engine: the bridge from "I noticed this mechanic" to "here's how I'd build it." Browse them all under Glossary.

Using the tool

Browse the catalog and filter by tier, perspective, or mechanic, then open any game for its summary, stats, and tags. The Analyze DNA action on a game's detail card takes that game's mechanic set and ranks every other game by how much it overlaps: a fast way to ask "what else plays like this?" or to assemble a study list around a specific system.

Copyright & cloneability

A recurring question while researching these games is "can I legally learn from this one?", and it separates two things people conflate. Legal status is uniform and boring: essentially everything in scope is still under copyright, and nothing enters the public domain for decades. Distribution status is where the variation lives. A game can be actively sold, quietly abandonware, or deliberately released as freeware or open source by the rightsholder.

That last category is the useful one: when a studio (or a community working from released source) puts code under an open-source license, you get a real, readable implementation of the systems you're trying to understand. The catalog flags titles that have it and links straight to the repository from the game's detail card: some are the original game's code, most are open-source engine reimplementations or rewrites.

Why open source matters here

For a learning tool, a readable open-source implementation is the most valuable artifact there is. A description tells you a mechanic exists; real source shows you how it was actually built: the data structures, the edge cases, the thousand small decisions a write-up never captures. That's the whole point of flagging it. Not "this game is free," but "here's a working system you can read, then rebuild from scratch yourself."

Whether code survives is a story about the companies, not the games. A title's source is studyable today mostly because of what happened to the studio behind it. Some rightsholders chose, years later, to release old code under an open license once it had no commercial value. id Software did it with Doom and Quake, Bungie with Marathon, Toys for Bob with Star Control II. Some studios folded and a community rebuilt the engine from the binary so the game could keep running. And some code is simply lost or in limbo: rights split across acquisitions, source tapes gone, an IP so tangled nobody can legally release what may still exist. The same mechanic can be one click from a readable implementation or permanently sealed, for reasons that have nothing to do with the game and everything to do with who ended up owning it.

Where the pointers come from, and the bar they clear. They're the result of a dedicated research pass held to one standard: the code has to be readable the moment you click through, openly-licensed source you can study in the browser. That covers official open-source releases by the rightsholder, source-available code under a study or non-commercial license, and open-source reimplementations, engines, ports, and from-scratch successors. We deliberately skip raw ROM decompilations and leaked code, because the aim is clean, readable source to learn from, not a legal gray area. Each pointer names the project and links straight to it.

How to use them. When a game carries a source block, treat it as a study target: read the open-source heir or engine to see how the system really works, then reimplement the part you care about from scratch as an exercise. Two honest notes. A from-scratch successor (Endless Sky for Escape Velocity, say) teaches the kind of game, not the original's exact code. And while the source is always free to read, some reimplementations still need the original data files to actually run the game.

This is not legal advice. Licenses change and repositories move; many reimplementations still need the original data files, which means owning the game. Verify the current license on a repository itself before relying on it for anything you intend to distribute.